Copilot Studio Governance for Enterprise Agent Estates

Copilot Studio Governance: What Every Agent in Your Estate Answers For

By Michael Branson | August 24, 2026

Quick answer. Copilot Studio governance answers five questions about every agent: what it can reach, what it can do, whose identity it runs under, what its release test proved, and who retires it. An agent with no owner on record is an agent nobody approved.

Copilot Studio put agent building inside the reach of people who do not write code, which is the point of the product and also the governance problem it creates. Agents accumulate the way apps and flows accumulated before them. One department builds something useful, three more copy the pattern, and a year later nobody can say how many agents exist, what they read, or whose permissions they borrow when they answer a question. The controls are not the gap. Microsoft ships them in the tenant’s admin centers, in Microsoft Entra, and in the authoring surface itself. The gap is the record: a written answer, per agent, to five questions, with a name against each answer. This guide sets out those five questions, who answers each one, and what has to be true for an agent to reach production and to stay there.

What This Guide Governs, and What the Build Pages Own

Building an agent and governing an estate of them are different jobs, done by different people, on different clocks. A page that tries to do both produces a document the security team cannot use and the makers will not read. So the boundaries come first.

How agents get built, architected, integrated and delivered is the territory of Microsoft Copilot Studio Development Services for Enterprise-Grade Custom Copilots, which describes the build and what an engagement covers. Once agents are live, keeping them fed, watched and supported is a standing operational job with its own economics, set out in Who Maintains and Supports AI Agents After They Are Built?. This guide sits between those two: the decisions that have to be made and recorded before an agent is allowed to run, and the rules that decide when it stops running.

Two more boundaries. Whether your Microsoft 365 tenant is in a state where first-party Copilot can be turned on safely is a separate decision with its own gates, worked in full in Is Your Microsoft Environment Ready for Copilot? What Must Be True First; agent governance assumes that decision is made there and restates none of it. And Copilot Studio agents live inside Power Platform environments, so the maker governance framework underneath them, environments, data policies, and who is allowed to build at all, is the subject of Designing a Power Platform Governance Framework That Holds Up in a Regulated Enterprise. Agent governance inherits that framework rather than replacing it. Above both sits the enterprise AI governance frame, the one model that covers AI use across Microsoft 365, Azure and Power Platform; the agent estate is one province of that frame, and the questions below are the province-level ones.

The Agent Record: Five Questions, One Owner Each

The instrument that makes agent governance real is unglamorous. It is a list of every agent in the tenant, one row per agent, and five answers in that row instead of five intentions. An organization that keeps this hands an auditor an index of the evidence instead of assembling one from scratch. An organization without it reconstructs history from admin center exports while somebody senior waits.

Three things about this record are load-bearing. First, the rightmost column above names a role instead of a team, and the copy you keep replaces each role with the name of the person who holds it, because a question owned by a committee is unanswered on the day it is asked. Second, the five questions are not all one person’s job; where a single administrator answers all five, the estate has concentrated its risk in one person’s calendar. Third, the record is kept per agent rather than per platform, because the interesting failures are agent-specific: this agent reads a folder it should not, that agent writes to a system nobody expected.

The owner of an agent is the business owner, not the maker. Makers move teams and leave the company; the function that depends on the agent stays. Where the maker and the owner are the same person, the record says so, and the review inherits the risk that both roles disappear together. Where two of the record’s owners disagree, the one who carries the damage decides.

Data: What an Agent Can Reach

An agent’s answers are bounded by the knowledge it is grounded on and the generation settings it runs under, so the first governance question is a scoping question before it is a security one. An agent pointed at a curated set of sites is a different object from an agent pointed at everything its creator can read, and the two deserve different approvals even though the authoring effort is identical.

Two mechanisms sit under this question, and only the first of them blocks anything. Data policies govern which knowledge sources an agent can be grounded on: Microsoft’s guidance on Copilot Studio security and governance lists knowledge sources alongside authentication, actions, connectors and skills, HTTP requests, publication to channels, and triggers as the capabilities administrators govern through those policies. Sensitivity labels then travel with the content: where the knowledge source is SharePoint, makers and users can see the highest sensitivity label applied to the sources used in an agent’s response, which surfaces the labels those sources carry today without saying whether the labels are correct.

What neither mechanism does is decide scope for you. The governance decision is whether this agent, for this audience, is grounded on a named set of sources approved by whoever owns that content. Write that decision into the agent record with the approver’s name, and reopen it when the audience changes. Where an agent’s connections carry a maker’s or a service account’s permissions, widening who can talk to it widens who can reach its grounding without anyone touching a permission.

One limit belongs here rather than in a footnote: an agent inherits the permission problems already present in the content it reads. Where a site is overshared today, an agent grounded on it will surface that oversharing faster and more fluently than search ever did. That is a tenant hygiene problem with its own remediation sequence, and it gates the agent rather than the other way around.

Actions: What an Agent Can Do, and Who Approves It

Reading is the smaller half. An agent that can call a connector, trigger a flow, or make an HTTP request is a system that acts, and actions are where governance stops being a documentation exercise. The buyer question here is exact: what can it actually do, and who said it could?

The platform answer starts with data policies. Microsoft’s documentation for Configure data policies for agents states that data policies let you govern how agents connect and interact with data and services, both within and outside your organization, and that connectors are classified into business, non-business and blocked groups so that connectors in different groups cannot share data. Microsoft also records that data policy enforcement has been in effect for all tenants since early 2025 and that the per-agent exemption from that enforcement is no longer supported, so a tenant with no considered policy is running on whatever its defaults produce rather than on a decision. The classification draws a boundary between groups; it says nothing about what any one connector reaches once it is permitted.

The policy is the fence. Approval is the harder half, and it is a question about your organization, not about the product. Three rules turn a fence into a process. A connector that reaches a system of record needs the owner of that system to approve its use in an agent, by name, and that approval is written down where the next person can find it. An agent that writes rather than reads gets a second approver, because a wrong read exposes information to somebody who should not hold it, and a wrong write changes a system somebody else has to put back. And custom connectors and direct HTTP requests are reviewed one at a time, because a policy classification is not a substitute for reading the endpoint an action reaches. When those approvals disagree, the system owner’s refusal is the one that stands, because the platform team does not carry the consequence of a wrong write into somebody else’s system of record.

If connector approval is the argument your security and platform teams keep reopening, that is a conversation worth having with an architect from outside the argument. Talk to a senior AI architect

Identity: Whose Permissions Is the Agent Using?

Every action an agent takes happens under some identity. Two settings carry the main part of that answer, and neither settles it on its own: the agent’s authentication mode, which decides whether the person using it signs in, and the credentials its connectors and flows use, which decide whose permissions a connection carries. This is the question buyers phrase as the agent acting as whom, and it has three defensible answers and one indefensible one.

The signed-in user is where both of those settings start, and it is the safest general answer where each knowledge source, connector and flow enforces the end user’s permissions. The agent then reaches what the person talking to it can reach, and existing permissions keep working. The maker’s own credentials are the alternative, and Microsoft’s documentation on the Automatic security scan in Copilot Studio is direct about the resulting risk position: the default option for connectors and flows is end user credentials, and the scan warns the maker when that is changed to maker-provided credentials. The warning exists because the change quietly extends the maker’s reach to everyone who uses the agent. There are designs where that is correct, for an agent that must query a system ordinary users cannot touch, and when it is correct the agent record names that identity, the reason it is wider than the user’s, and the person who approved it.

The third answer is a dedicated service identity created for the agent, scoped to exactly what the agent needs, owned by the platform team, and reviewed like any other privileged account. That is the right shape for autonomous agents that act on a trigger rather than in a conversation, because there is no signed-in user to borrow from. It costs more to set up than borrowing a maker’s account, which is precisely why maker accounts keep getting borrowed.

The indefensible answer is no authentication at all. Microsoft’s documentation states that the default authentication mode is Authenticate with Microsoft, and that selecting no authentication allows anyone who has the link to interact with the agent. Public-facing scenarios exist where that is intended. No scenario justifies it happening without the decision being written down, and the same documentation notes that a new agent is shared with no one by default, so every widening of reach after that is somebody’s deliberate act.

Testing: What a Release Test Proves for a Probabilistic Agent

Traditional release testing asks whether the software does what it was specified to do. An agent built on a language model returns different words to the same question on different days, so the honest goal is narrower: a release test bounds what the agent will not do on the cases you check, and samples what it does well.

Four checks belong in an agent release, and none of them needs a test framework to start. Refusal behavior: ask the agent for the things it must decline, including data the person asking should not see, and confirm the refusal rather than assuming it. Grounding fidelity: for a set of questions with known answers, check that the answers come from the approved sources and that citations point where they should. Permission separation: run the same question as two people with different access and confirm the answers differ where the permissions differ. Action safety: exercise every action the agent can take in a non-production environment, including the failure path, because an action that half completes is worse than one that fails cleanly.

The evidence question matters more than the test design. Keep the question set, the date, the version tested and the result, because the value of that record arrives months later when somebody asks whether a behavior is a regression or a thing the agent always did. A test whose results were not retained cannot answer that, which makes it a demonstration and not a test. A check the agent fails stops the release: it waits until the behavior changes or until the scope narrows to exclude it.

Two limits belong in the same breath as the pass. A pass on a sampled question set says nothing about the questions nobody sampled, and the honest way to write that in a release note is as a coverage statement: these behaviors were checked, on this date, at this version. And the person who accepts the agent should be the business owner who will field the complaint when it answers badly, rather than the platform team that built the pipeline it shipped through.

Release criteria are easier to settle before the first agent ships than to revisit after it. Talk to a senior AI architect

Lifecycle: Environments, Solutions, Ownership and Retirement

An agent hand-edited in production has no designed rollback point, and the record of what changed before an answer went wrong is whatever the environment happened to retain. The lifecycle question is how an agent moves, and it has a documented shape. Microsoft’s guidance on how to Export and import agents using solutions describes moving agents across environments by adding an agent to a solution, exporting it, and importing it elsewhere, and states two constraints worth designing around: a managed solution cannot be exported, and not all agent components and properties are included in the export. The second constraint is the one that surprises teams at promotion time, so a promotion checklist names what has to exist in the destination environment already.

Environment structure carries governance weight that naming conventions cannot. Agents that touch regulated data belong in environments where the data policy, the sharing limits and the administrator set were decided for that risk class, rather than in the shared environment where personal productivity work lives. That structure is inherited from the platform framework instead of invented per agent, and that inheritance is why agent governance is cheap in a tenant that already has an environment strategy and expensive in one that does not.

Retirement is the part that costs nothing to skip on the day an agent ships, and skipping it is why estates accumulate. Three rules make it routine. Every agent gets a review date when it is created, and the review asks two questions: is anyone using it, and does the named owner still work here. An agent that fails either question goes back to its business owner first: a departed owner is replaced, and a seasonal or compliance agent is reviewed on its own cycle. An agent switched off anyway moves to a disabled state with its record intact rather than being deleted, because deletion destroys the evidence of what it could reach. And an owner departure is a governance event: the agent is reassigned or disabled inside the same process that handles the rest of that person’s access, rather than living on as an ownerless object holding production permissions.

The estate-level version of those rules is a standing sweep: a periodic list of agents with no usage, no owner, or no review since the last cycle, sent to people who can act on it. Administrators can monitor agent usage and Copilot adoption trends in the Copilot Hub in the Power Platform admin center, and the usage half of that list is only as good as what that view reports for each agent. The governance decision is who reads that list and what they can switch off without seeking a second approval.

When This Is Not the Work You Need

Some organizations reading this should not start with an agent governance model, and it is cheaper to say so here than to sell it.

If you have two agents, both built by one central team, both grounded on content that team already owns, you do not need a five-answer record per agent. Name an owner, write down what each agent reaches and what it can do, and revisit the question when a third department asks for one. If your problem is that first-party Copilot surfaces content people should not see, that is a permissions and labeling problem in the tenant, and no amount of agent policy will fix it; the readiness gates and the remediation sequence they name come first. If your agents are already live and the pain is operational rather than architectural, the monitoring, the support and the cost of running them, the operate-phase page named in the boundaries above describes that work, and this frame is its context. And if your agent estate sits mostly outside the Microsoft stack, the five questions still apply but the Microsoft mechanisms in the table do not, and the answers belong wherever those agents actually run.

What is left is the organization this guide was written for: agents multiplying faster than anyone is counting, a security team asking what they can reach, and no single document that answers it. i3solutions has been a Microsoft partner since 1997, and moving from an uncounted estate to a written record starts with writing down the five answers for the agents that already exist. Talk to a senior AI architect

Frequently Asked Questions

How should Copilot Studio agents be governed in an enterprise?

Govern them as objects with owners, not as a platform setting. Keep one record with a row per agent that answers five questions: what data it is grounded on, what actions it can take, which identity it runs under, what its release test proved, and when it is reviewed or retired. Each answer carries a named person, and the business function that depends on the agent owns it rather than the maker who built it. The platform controls behind those answers sit in the Power Platform admin center and in the agent’s own configuration; what the release proved and when the agent is reviewed are carried by the record itself.

How do we control what actions an agent can take?

Two layers. The platform layer is data policies, which govern how agents connect to data and services and classify connectors into business, non-business and blocked groups so that connectors in different groups cannot share data; Microsoft has enforced these policies across all tenants since early 2025, and per-agent exemptions are no longer supported. The process layer is approval: the owner of a system of record approves its connector for agent use by name, an agent that writes gets a second approver, and each custom connector and each direct HTTP request is reviewed on its own, because classifying a connector is not the same as reviewing the endpoint it reaches.

Whose identity does a Copilot Studio agent act under?

One of three defensible identities. Running as the signed-in user is where both the authentication mode and the connector credential setting start, and it keeps existing permissions working. Running with the maker’s credentials extends the maker’s reach to everyone who uses the agent, which is why the automatic security scan in Copilot Studio warns a maker who switches connectors and flows away from end user credentials. A dedicated service identity, scoped and owned by the platform team, suits autonomous agents that have no signed-in user to borrow from. Unauthenticated agents are reachable by anyone holding the link and belong only to deliberately public scenarios.

What testing should custom agents pass before deployment?

Four checks, plus retained evidence. Confirm refusal behavior on the requests the agent must decline. Confirm grounding fidelity by asking questions with known answers and checking that citations point at approved sources. Confirm permission separation by running the same question as two people with different access. Exercise every action in a non-production environment, including its failure path. Then keep the question set, the version, the date and the results, because a language model returns different words on different days and a record of what was true before is the only way to tell a regression from normal variation.

How do we retire agents nobody uses or owns?

Give every agent a review date when it is created, and make the review ask two questions: is anyone using it, and does the named owner still work here. An agent that fails either question is routed to its business owner before anything is switched off, so a seasonal or compliance agent is judged on its own cycle and a departed owner is replaced. An agent switched off anyway is disabled with its record kept rather than deleted, because deletion destroys the evidence of what it could reach. Treat an owner’s departure as a governance event handled inside the same process that removes the rest of their access. At estate level, run a standing sweep for agents with no usage, no owner, or no review since the last cycle, and give one person the authority to switch them off.

What is the difference between agent governance and Power Platform governance?

Power Platform governance decides who can build, in which environments, with which connectors, under which data policies. It is the ground an agent estate stands on, and it covers apps and flows in the same breath. Agent governance is the object-level layer above it: for this specific agent, what is it grounded on, what can it do, whose identity does it use, what did its release prove, and when does it end. A tenant with a working platform framework can add the agent layer quickly. A tenant without one is building both at once.

Related Reading

• Custom AI Consulting Services for Governed Microsoft Enterprise AI, the AI practice this guide belongs to, and what governed delivery of custom AI looks like as an engagement
• Hire a Firm for Microsoft 365 Copilot Governance After Deployment, the operating program once first-party Copilot is live across the tenant
• Designing a Power Platform Center of Excellence That Holds Up in a Regulated Enterprise, the platform function that owns environments, policies and maker enablement
• Microsoft Entra ID Governance for Regulated Enterprises, the identity layer underneath the question of whose permissions an agent uses

About the Author

Michael Branson co-founded i3solutions and brings executive, operational, and technical perspective to organizations running complex, secure, and mission-critical Microsoft estates. He works with enterprise teams on the governance and architecture decisions that determine whether a platform investment holds its value.