Governing Microsoft 365 Copilot Agents

Microsoft 365 Copilot agents ground their responses in the Microsoft Graph permissions of the user who invokes them, which means a Copilot agent cannot surface a document, email, or file the invoking user could not already access directly. That grounding model is a sound default for the built-in Copilot experience. The governance challenge sits elsewhere: Copilot Studio lets any licensed maker, not just central IT, build and publish a custom agent that connects to data sources beyond that default grounding model, and that self-service capability produces agent sprawl faster than most organizations' review processes can track it.

What the Graph-grounded permission model covers

Microsoft's decision to ground Copilot's default behavior in the existing permission model of Microsoft 365 — rather than granting a Copilot agent its own independent, broader access — is the right default and a meaningful design choice:

• Search-based grounding respects existing sharing. A Copilot agent answering a question by searching SharePoint, Exchange, or OneDrive content surfaces results filtered by the same permissions that already govern what the invoking user can see through Microsoft 365's native search.
• No privilege escalation through the default experience. Because grounding is scoped to the user's own access, a Copilot agent cannot become a mechanism for a user to see content their role would not otherwise permit, which is the most basic and important governance property any agent operating over sensitive corporate content needs to have.
• Tenant-level admin controls govern which Copilot capabilities are available to which users, giving IT a baseline lever over rollout even before considering custom agent publishing specifically.

For the built-in Copilot experience, answering questions from content the user already has access to, this is a coherent, low-risk model, and it reflects a governance principle worth generalizing: an agent's access should be derived from the invoking user's existing permissions by default, not granted independently and then hoped to be scoped correctly.

Where the model changes: Copilot Studio and citizen-developer publishing

The governance picture changes substantially once Copilot Studio enters the picture. Copilot Studio is built specifically to let business users, not only developers, build custom agents with their own defined actions, knowledge sources, and connectors — deliberately lowering the barrier so that domain experts can build an agent for their own workflow without waiting on a central engineering team. That is a genuine productivity win, and it is also precisely the mechanism that produces the governance gap:

1. Publishing does not require central IT approval by default in every tenant configuration. Depending on how an organization has configured Copilot Studio governance settings, a maker can build and share an agent with a team or the broader organization without a security review gating that publication.
2. Custom agents can connect to non-Microsoft data sources and external APIs. Once an agent's knowledge sources or actions include a connector to a system outside the Microsoft 365 tenant, the Graph-grounded permission model that governs the default Copilot experience no longer applies — data access is now governed by whatever the connector itself was configured to allow.
3. Agent volume grows faster than review capacity. A self-service building tool used by a large maker population, by design, produces more agents than a small governance team can individually review in the time between creation and publication, which is the same dynamic behind the rise of shadow AI across every low-code and no-code platform, not unique to Microsoft.
4. Ownership becomes unclear over time. An agent built by an employee who has since changed teams or left the organization can keep running, with nobody clearly accountable for reviewing whether its connectors and permissions still make sense.

A cross-boundary risk checklist

What governs maker-published agents specifically

A cross-vendor identity mapping, a unified audit trail, and general ownership-review discipline are the same shared controls covered in machine identity vs. workload identity vs. agent identity and SSO and SCIM for enterprise identity in AI tools, and they apply here without much Microsoft-specific texture.

What is specific to Microsoft 365 is the maker-publishing pipeline itself:

• A tenant-wide inventory that captures the Graph-grounding boundary explicitly — every published Copilot Studio agent, whether its knowledge sources stay inside SharePoint/Exchange/OneDrive or extend to a connector, and its current owner. Building an AI agent inventory covers what fields make that inventory actionable rather than a static list nobody reviews.
• A publishing review gate keyed to that same boundary — lightweight self-service for agents that stay inside Graph-grounded permission inheritance, and a required review step the moment an agent's connectors reach outside the Microsoft 365 tenant.
• Regular ownership review that catches orphaned agents before their unreviewed connectors become an incident rather than a routine cleanup item, since Copilot Studio's maker population turns over faster than a typical IT asset inventory.

The Microsoft agent governance toolkit and independent control planes post covers Microsoft's own broader governance tooling for this population and where an independent layer still adds value alongside it.

What good looks like

1. Publishing in Copilot Studio is gated by a review step scaled to connector sensitivity, not uniformly open or uniformly blocked.
2. A tenant-wide inventory lists every published agent, its connectors, its knowledge sources, and a current, accountable owner.
3. Agents connecting outside the Microsoft 365 tenant boundary are reviewed with the same rigor as any other third-party integration, not treated as a low-code exception.
4. Orphaned agents are surfaced and reassigned or deactivated on a defined cadence, not left running indefinitely after an owner departs.
5. Audit coverage spans both Microsoft 365's native logs and any external system a custom agent's connectors reach.

The Graph-grounded default is a genuine governance strength for Copilot's built-in experience. The real work is governing what Copilot Studio was deliberately designed to make easy — letting far more people than central IT build agents that connect to far more systems than the default experience ever touches.

Common questions

Does the Graph-grounded permission model apply to every custom agent built in Copilot Studio? It applies to knowledge sources drawn from Microsoft Graph — SharePoint, Exchange, and similar Microsoft 365 content. Once a maker adds a connector to a non-Microsoft data source or an external API, that added capability is governed by the connector's own configuration, not by the invoking user's Graph permissions.

Can a business user really publish an agent without IT ever reviewing it? It depends entirely on how an organization has configured Copilot Studio's governance and admin settings. Some tenants require approval before an agent is published broadly; others leave that door open by default. Confirming your own tenant's actual configuration, rather than assuming a review gate exists, is the first thing to check.

Is an orphaned Copilot Studio agent a realistic risk, or a theoretical one? It is a realistic and common one for any self-service building tool with a large maker population — the same pattern shows up whenever citizen developers build automations, dashboards, or integrations without a formal handoff process when they change roles. An agent with a live connector to an external system does not stop running just because its owner moved on, which is exactly why an ownership review cadence matters.

What is the single highest-value action to take first? Establish the tenant-wide inventory before anything else. Without a list of every published agent, its connectors, and its owner, none of the other controls — review gates, ownership cleanup, audit coverage — have anything concrete to act on.