Copilot Studio and Agent 365 Governance Guide | Calance

Most organizations have already built a Copilot Studio agent. A small team connected a SharePoint library, wrote instructions, tested a few questions, and showed the result to leadership. The demo worked. Everyone was impressed.

Then someone asked: "Can we put this in production?"

That question changes everything. A prototype retrieves information and answers questions inside a controlled test. A production agent connects to business systems, calls APIs, updates records, triggers workflows, and (increasingly) acts on events without someone typing a prompt. The risk isn't limited to a bad answer. It's an agent executing the wrong action with the wrong credentials against the wrong system, and nobody noticing until the damage is visible.

This is where Copilot Studio and Agent 365 enter as complementary layers. Copilot Studio is Microsoft's agent-building platform: design, connect, test, publish. Microsoft Agent 365 (generally available since May 1, 2026) is the enterprise control plane: inventory, identity, lifecycle, observability, security, and compliance across your agent population. One builds the agent. The other helps IT understand, control, and govern it after it exists. Neither replaces the other, and neither covers the full governance problem alone.

This guide from Calance walks through the architecture, decisions, and operating model IT needs to move from "working demo" to "production system we're willing to support." Every section addresses a specific governance question, with the frameworks and controls behind the answer.

Start by Separating the Agent Builder from the Enterprise Control Plane

The most common mistake in early Copilot Studio and Agent 365 planning is treating one product as the complete governance answer. Microsoft distributes agent governance across several surfaces, and each one owns a different part of the problem.

AGENT GOVERNANCE CONTROL MAP

Copilot Studio governance starts with understanding these boundaries. Microsoft's zoned governance documentation is explicit that Agent 365 operates alongside existing Power Platform and Microsoft 365 governance mechanisms. It doesn't absorb them.

So when someone says "we've deployed Microsoft Agent 365, governance is handled," the correct follow-up is: which layer? Agent 365 gives you fleet-wide inventory and lifecycle visibility. Power Platform gives you environment and connector control. Entra gives you identity. Defender gives you threat detection. Purview gives you compliance evidence. Business governance gives you the human decisions that no product can automate. IT needs all of them working together, and organizations working with an experienced Microsoft governance partner understand why.

Classify Agent Risk Before Anyone Starts Building

A SharePoint FAQ agent and an autonomous procurement agent that approves purchase orders shouldn't pass through the same review. But most organizations start with a single approval process (or none at all), and every agent gets identical treatment.

AI agent governance works better when it's proportional to consequence. Before anyone opens Copilot Studio, the intake process should answer one question: how much damage could this agent cause if it behaves incorrectly?

AGENT RISK CLASSIFICATION MODEL

A low-risk agent reads approved content, answers questions, and has no write access. Think: an IT policy FAQ bot for a single department. A moderate-risk agent uses connectors with user-delegated permissions to create or update records, like a helpdesk agent logging tickets in ServiceNow.

High-risk agents write to business-critical systems, act on events, or serve broad internal audiences, like a supply chain agent that updates inventory and triggers vendor notifications. Critical agents carry financial, regulatory, or safety implications, operate with persistent identities and autonomous triggers, and communicate externally without human confirmation.

The tier determines everything downstream: which environment, which connectors, which identity model, how much testing, who approves publication, and how often the agent gets reviewed. Set the tier first. Configure the controls second.

Put Environment Strategy Ahead of Individual Agent Configuration

Copilot Studio agents are created inside Power Platform environments. Microsoft's environment architecture guidance describes these as logical containers that define data boundaries, security roles, connector policies, and lifecycle separation.

That makes the environment your first real governance boundary. Before you debate an individual agent's connector list, decide where it's allowed to exist.

ENVIRONMENT PROMOTION PATH

The path scales with organizational size. A 200-person company probably doesn't need 4 separate environments for a low-risk knowledge agent. A 10,000-person enterprise running 50 production agents across finance, HR, and operations probably does. Organizations designing their Power Platform environment architecture should match isolation to risk tier from the start.

Copilot Studio governance at the environment level means controlling who can build, what data they can touch, which connectors they can use, and whether they can push anything to production without review. Power Platform data policy controls enforce these rules by classifying connectors into Business, Non-business, and Blocked groups. Microsoft now enforces these policies in real time; earlier exemptions from enforcement no longer apply.

One more thing. Don't create a dedicated environment for every small agent. That creates sprawl and overhead that defeats the purpose. Low-risk agents can share a governed environment. High-risk and critical agents earn their own.

Give Every Production Agent an Identity Model and Accountable Humans

Every agent runs under some identity. The question IT has to answer early: whose permissions does this agent use when it calls a tool or retrieves data? And (equally important) who is responsible for this agent six months from now? Copilot Studio and Agent 365 address both questions, but through different mechanisms.

IDENTITY + ACCOUNTABILITY CARD

Delegated access means the agent works within the signed-in user's permissions and is the safest default for conversational agents. Application-level access means the agent operates with its own permissions, independent of any user session, useful for background processing and event-triggered work where IT controls exactly what those permissions include.

Persistent agent identity (through Microsoft Entra Agent ID) gives an agent its own identity that can accumulate access over time. Microsoft's content-sharing guidance explicitly describes these identities as persistent and potentially accumulative. That changes governance: you now need access reviews for the agent itself, managed through your Microsoft 365 identity and access services.

Then there's the human side. Microsoft's Entra Agent ID ownership model separates technical owners from business sponsors. The owner maintains configuration. The sponsor decides whether the agent should continue to exist. When the maker leaves the company, the sponsor is the person who knows whether the agent still matters. Without both roles assigned, you get orphaned agents that nobody can answer questions about and nobody has authority to retire.

Govern Connectors, Tools and Credentials Before You Govern Prompts

Most AI governance conversations start with prompt safety: injection, hallucination, output quality. Those matter. But for a production agent connected to business systems, the bigger risk sits in what the agent can do after it reasons.

An imperfect answer is inconvenient. An incorrectly executed payment, CRM update, permission change, or record deletion is materially worse.

Copilot Studio agents can use Microsoft connectors, third-party connectors, custom connectors, APIs, HTTP requests, agent flows, tools, and (increasingly) MCP-connected capabilities. Each one carries two questions: what can it read, and what can it change?

TOOL PERMISSION MATRIX

Copilot Studio governance for connectors works through Power Platform data policies. Admins classify connectors into Business, Non-business, and Blocked groups. Policies can also restrict HTTP requests, skills, publishing channels, event triggers, and unauthenticated agents.

Credential risk deserves specific attention. Copilot Studio allows tools to operate using the end user's credentials or maker-provided credentials. Maker-provided credentials are the hidden risk. If the maker has broader access than the end user, the agent running through the maker's connection can expose capabilities beyond what the user would normally reach. Microsoft's authentication controls allow administrators to restrict maker-provided credentials and force tools toward user-specific authorization.

For MCP-connected tools, Microsoft warns that third-party MCP servers may involve data leaving organizational boundaries, credential sharing, different retention practices, and reduced human oversight. Agent 365's higher governance tiers can control which tools agents may access tenant-wide.

Make Data Access Intentional Before Connecting More Knowledge

An agent that can technically access a SharePoint site doesn't mean that site should be in the agent's approved design. Technical capability and governance approval are different things.

Before connecting a knowledge source, run it through a decision filter.

DATA ACCESS DECISION FILTER

Organizations that went through their Copilot readiness assessment already did some of this work. SharePoint permissions, sensitivity labels, and access reviews apply to agents the same way they apply to Copilot. Calance's SharePoint Governance Framework covers the content and access layer in depth. The agent governance question builds on top: which of those governed sources should this specific agent be allowed to reach?

Two practical rules. First, start with the minimum data an agent needs to fulfill its purpose. You can always expand access through a change request. Pulling back access after users depend on it is harder and more disruptive.

Second, treat third-party and external data connections with extra scrutiny. Data leaving your Microsoft tenant through a connector or MCP server follows that service's retention, location, and security policies.

Decide How Much Autonomy an Agent Earns

A conversational agent waits for someone to ask a question. An autonomous agent acts on events, schedules, or conditions without a human typing a prompt at that moment.

That distinction matters because the risk profile changes significantly. Copilot Studio now supports event-triggered agents, and Microsoft notes that event-trigger executions affect billing. An agent firing every few minutes generates consumption and risk whether or not anyone opened a chat. Organizations designing enterprise agentic AI programs need to plan for this from day one.

AI agent governance for autonomous behavior should follow an escalation model. The higher the consequence, the stronger the controls.

AUTONOMY LADDER

Copilot Studio and Agent 365 together provide the controls for this ladder. Copilot Studio agent flows support human-in-the-loop actions and approval stages. Agent 365 provides observability into tool invocations. Defender can add runtime protection for supported scenarios.

The principle: autonomy should be earned by evidence and bounded by consequence. Read-only and reversible actions can receive more autonomy. Financial, destructive, external, regulatory, or identity-changing actions need stronger approval and supervision.

Microsoft's own guidance for autonomous agents recommends human oversight for critical actions and incremental expansion as agents demonstrate reliability. Start an agent at Level 2 or 3. Watch it perform. Review the evidence. Then decide whether it earns Level 4 or 5.

Don't blanket every action with human approval (that defeats the point of automation). And don't skip approval because "agents are meant to act." Match the control to the consequence.

Treat an Agent Release Like Software Deployment, Not Content Publishing

A production agent isn't a blog post. You don't write it, click Publish, and move on. It's software that connects to business systems, acts on data, and runs under an identity. Treat the release process accordingly.

Copilot Studio agents support Power Platform solutions and can be promoted between environments using pipelines. Microsoft's solutions documentation supports patterns like development to validation to limited release to production. That's the same ALM discipline your development team already uses for other Power Platform work.

PRODUCTION RELEASE GATE

An agent may progress to production only when each gate is cleared:

Copilot Studio now has formal evaluation capabilities: test conversations, evaluation methods, expected-behavior comparison, and tool-selection analysis. Some evaluation features remain in Preview. Microsoft's Copilot Agent Kit adds conversation analysis, value assessment, and automated testing through pipelines.

"The maker chatted with it and it looked fine" is not production evidence. Test cases should inspect the full chain: input, reasoning, tool selection, tool execution, and output. Copilot Studio governance for releases should require documented test evidence proportional to the agent's risk tier. A low-risk FAQ agent might pass with 20 validated test conversations. A critical finance agent needs regression tests, permission tests, and failure-mode tests.

Calance works with organizations to design these release processes, connecting agentic AI development with controlled pilot deployment and production readiness across Microsoft 365.

Control Publishing, Discovery and Shadow-Agent Growth

Building an agent and making it broadly available are separate control points. Microsoft treats them that way, and IT should too.

Agents built in Copilot Studio can be published to supported channels, but making Copilot Studio agents broadly available through Microsoft 365 or organizational catalogs can involve administrative approval. The Microsoft 365 Agent Store is becoming a governed distribution surface where IT can influence which agents users discover and access.

Microsoft Agent 365 provides the registry. According to Microsoft's registry integration documentation, Copilot Studio agents now automatically appear in the agent registry when created (a change from earlier preview behavior, where only published agents appeared). That means IT gets visibility earlier in the lifecycle.

But visibility isn't approval. The Microsoft 365 admin center surfaces governance conditions including agents without owners, pending agent requests, agents at risk, and agents with exceptions. Organizations managing their Microsoft 365 governance and administration should be monitoring these signals actively.

AGENT INVENTORY STATES

Shadow agents are the biggest inventory risk. These are agents built or running outside formal oversight. Microsoft's approach isn't to ban them outright. The model is: discover, register, assign an owner, right-size access, monitor, and retire if necessary. Microsoft Defender can help discover AI agents across the organization.

The governing objective shouldn't be "stop employees from building." Microsoft's Center of Excellence guidance explicitly warns against a gatekeeper model that reviews everything so slowly that teams route around IT. The better goal: make the approved path easier and faster than the shadow path.

Extend Identity, Security and Compliance Controls into Runtime

Once an agent reaches production, governance shifts from "what did we approve?" to "what is actually happening?" Copilot Studio and Agent 365 connect to four runtime governance surfaces, each covering a different dimension.

RUNTIME CONTROL PLANE

AI agent governance at runtime means different teams need different views. The identity team needs to know which agents have their own credentials and what they've accumulated. Security operations needs to know if any agent is behaving suspiciously. Compliance needs to know what data agents touched and whether they can produce evidence for an audit. IT administration needs to know which agents are running, who owns them, and whether any are flagged.

Microsoft Agent 365 provides native telemetry for Copilot Studio agents. According to Microsoft's Agent 365 builder documentation, invocation telemetry and tool/connector telemetry flow automatically without the developer adding SDK instrumentation. That's a real advantage of building inside Copilot Studio: observability comes with the platform.

One important caveat. Some Defender runtime protection capabilities for Copilot Studio agent tool invocations remain documented as Preview in Microsoft's runtime protection guidance. Don't assume every action-level protection is GA. Check current documentation for your specific scenario, plan for the gap, and note that Agent 365 doesn't impose internal runtime behavior on third-party agents. It provides identity, policy, inventory, and observability guardrails, but third-party implementations still need to support those controls correctly.

Monitor Cost and Business Value Alongside Security

An agent can be secure, compliant, well-tested, correctly owned, and still not worth running. Governance without a value lens creates zombie agents: technically healthy, practically useless, quietly consuming resources.

Cost governance operates on multiple planes. Runtime consumption through Copilot Credits can grow silently when event-triggered agents fire on schedules or system events, even when nobody is actively chatting. Agent 365's per-user licensing model (with security capabilities that moved under Agent 365 effective July 1, 2026) is a separate budget item. And operational costs like support, maintenance, connector fees, and monitoring overhead are real even when they don't show up in a Microsoft invoice.

KEEP / IMPROVE / RESTRICT / RETIRE SCORECARD

Copilot Studio agents should have a review cadence tied to their risk tier. Low-risk agents might get an annual check. Critical agents should be reviewed quarterly or after any significant change.

The scorecard gives the business sponsor and IT a shared framework for the hardest governance decision: when to turn something off that somebody built.

Build an Operating Model That Survives the Original Maker

The biggest governance failure isn't a misconfigured connector or an overprivileged identity. It's an agent that nobody can explain, nobody can maintain, and nobody has the authority to turn off.

A production agent should carry documented answers to these questions. Who owns it? Who sponsors it? What risk tier is it? Which environment contains it? Which data does it use? Which tools can it call? What credentials does it use? What tests passed? Who approved publication? What audiences can use it? How is it monitored? When is the next review? What would cause it to be disabled?

That's what turns Copilot Studio governance from policy documents into operating evidence.

BUILD-TO-RETIRE OPERATING LOOP

The loop doesn't end at publication. Recertify means the business sponsor confirms the agent still serves its purpose, still operates within approved boundaries, and still justifies its cost and risk. If the sponsor can't answer those questions, the agent should be restricted or retired.

AI agent governance at this level is an operating discipline. It connects business purpose to technical controls to ongoing accountability.

This is where Calance works with organizations across the full loop: Copilot Studio and Agent 365 architecture, Power Platform environment design, Microsoft 365 governance, identity and access, security controls, human-in-the-loop workflows, testing, pilot deployment, and operational monitoring. The goal is an agent program that IT can support at scale, with evidence behind every production agent and a clear path to retirement when the agent's job is done. Organizations building their first production agents or scaling an existing program can talk to Calance's Microsoft and AI team about designing a governable agent operating model.

Copilot Studio and Agent 365 FAQs

What Is the Difference Between Copilot Studio and Agent 365?

Copilot Studio is Microsoft's agent-building platform where you design, connect, test, and publish agents. Agent 365 is the enterprise control plane for inventory, identity, lifecycle, observability, security, and compliance. One builds agents. The other helps IT govern them across the organization.

Does Agent 365 Replace Copilot Studio Governance?

No. Agent 365 operates alongside existing Power Platform and Microsoft 365 governance mechanisms. Microsoft is explicit about this. Power Platform still controls environments, data policies, and connectors. Agent 365 adds fleet-wide inventory, lifecycle management, and enterprise-level visibility on top of those existing controls.

Do Copilot Studio Agents Automatically Appear in Agent 365?

Yes. Current Microsoft documentation states that Copilot Studio agents automatically appear in the agent registry when created. This changed from earlier preview behavior where only published agents were visible. Agents also send invocation and tool telemetry to Agent 365 without requiring manual SDK instrumentation.

How Should IT Control Who Can Build Copilot Studio Agents?

Through Power Platform environment strategy. Restrict maker access using security groups and environment-level roles. Apply data policies to control which connectors are available. Separate experimentation environments from production. Match the level of control to organizational risk tolerance and the agent's risk tier.

Should an Agent Use the Maker's Credentials or the User's Credentials?

Default to user-delegated credentials for most scenarios. Maker-provided credentials carry risk because the agent may act with broader access than the end user normally has. Microsoft provides admin controls to restrict maker-provided credentials. Reserve them for scenarios where the action and access model have been explicitly reviewed and approved.

Can Copilot Studio Agents Act Autonomously?

Yes. Copilot Studio supports event-triggered agents that act on external events without a user typing a prompt. These executions affect billing. Higher-consequence autonomous actions should include human-in-the-loop approval, scoped permissions, runtime monitoring, and defined rollback procedures. Autonomy should increase incrementally based on demonstrated reliability.

How Does Microsoft Entra Help Govern AI Agents?

Entra provides agent identities, authentication, and Conditional Access for agent identities in supported scenarios. The Entra Agent ID model separates technical owners from business sponsors. Conditional Access policies can block, permit, or evaluate risk for agent identities, giving IT identity-level governance over the agent population.

What Do Defender and Purview Add to Agent Governance?

Defender covers security posture assessment, threat detection, and runtime protection for supported agent actions (some capabilities remain Preview). Purview covers audit, DLP, sensitivity labels, eDiscovery, retention, and compliance. Together they give security and compliance teams visibility into what agents are doing with data and systems.

How Should Companies Manage Shadow AI Agents?

Discover them first. Microsoft Defender can identify AI agents across the organization. Then register, assign ownership, assess risk, and either bring them under governance or retire them. The goal isn't to ban building. It's to make the approved path faster and easier than the ungoverned path.

How Can Calance Help Build Governable Microsoft AI Agents?

Calance works across Copilot Studio agent development, Power Platform environment design, Microsoft 365 governance architecture, identity and access, security controls, and operational monitoring. The focus is connecting agent building to enterprise governance so IT can support production agents at scale.