Sharing Custom Copilot Agents Across Your Tenant: The Governance Guide

The first ten agents a tenant produces are usually easy to reason about. The next hundred are not. Once Copilot Studio agents proliferate, the question of how they get shared, discovered, retired, and audited becomes a distinct governance problem that most organizations discover only after it has already gotten away from them.

Our consultants see the same pattern across enterprise deployments: makers publish agents through whichever surface is easiest, consumers pin whichever agent they found first, and the administration team has no reliable answer to "who owns this agent and what data does it touch." This guide walks the sharing surfaces enterprises must govern, the audit and lifecycle problems they create, and a workable operating model.

The Sharing Surfaces You Need to Govern

Custom Copilot agents can reach an end user through more than one path. Each path has its own permission model, its own audit trail, and its own failure mode. A governance program that only monitors one of them is effectively blind to the rest.

• Teams app catalog. Publishing an agent to the Teams tenant app catalog makes it discoverable inside the Teams client. Approval is controlled by Teams administrators; the underlying agent identity remains in the maker's Power Platform environment.
• Power Platform environment sharing. Direct sharing to users, groups, or security groups from inside Copilot Studio. This is fast, but it bypasses any centralized catalog and is easy to lose track of.
• Direct link. A pasted URL that takes a user straight to the agent. Whether the recipient can actually use it depends on the agent's sharing permissions, but the link itself is uncontrolled and shareable in email, chat, or documents.
• Organizational agent catalog. The curated tenant catalog surfaced inside Microsoft 365 Copilot for consumers. This is the most visible surface and typically the one with the tightest approval gate.

The consequence of not treating these as one system is that a single agent may be published to the Teams catalog with one owner, shared directly to a security group with another, and reachable by direct link to anyone in the organization. The three views disagree about who is entitled to use it.

The Audit and Lifecycle Problems

Once agents multiply, three problems compound quickly. First, ownership drift: the original maker leaves the company, the agent keeps running, and nobody is accountable for it. Second, connector sprawl: agents accumulate connectors to line-of-business systems that were fine at pilot but were never re-reviewed at enterprise scale. Third, knowledge drift: the SharePoint site or Dataverse table the agent points at gets restructured, and the agent begins returning stale or incorrect answers with no signal to the users trusting it.

The audit story is worse. Copilot Studio and Purview capture activity, but "AgentX was invoked 4,300 times last month" is not useful if nobody can tell you who owns AgentX, what data it can reach, or whether it is still approved.

An Agent Registry Pattern

The single most valuable control we recommend is an internal agent registry — a lightweight system of record that a governance team maintains for every agent that reaches production. It does not replace the platform's native admin views. It reconciles them.

At minimum, the registry should hold:

• Agent ID, display name, and the Power Platform environment it lives in
• Business owner (a named human, not a distribution list) and technical owner
• Purpose statement and intended user population
• Knowledge sources connected, including sensitivity classification of each
• Connectors and actions in use, with an approval decision on each
• Data classification of inputs and outputs
• Review date and retirement criteria
• Approved sharing surfaces (Teams catalog, org catalog, direct share, none)

The registry becomes the enforcement point. If an agent is not in the registry, it is not approved for tenant-wide sharing. This is the same pattern mature enterprises apply to APIs: without a registry, you have no coherent inventory.

For guidance on stitching this into a broader control set, our Copilot governance service covers the registry pattern, the integration with Purview audit, and the operating cadence around review.

Sensitivity-Label Enforcement on Agent Knowledge

A frequently overlooked control is sensitivity labeling on the knowledge that agents are grounded on. Copilot honors sensitivity labels on SharePoint content, which means an agent grounded on a labeled document library will respect those labels when it responds. The failure mode is agents grounded on unlabeled or over-permissive knowledge, which then leak information at query time to any consumer with access to the agent.

The rule we recommend enforcing at the tenant level:

• No agent may be published to the org catalog or Teams tenant catalog if its knowledge sources contain unlabeled content.
• Knowledge sources labeled at or above a defined threshold (for example, Confidential) require an additional review before the agent can be shared beyond a named security group.
• Any change to the knowledge source after publication triggers a re-review.

This is enforced through a combination of Purview classification, environment strategy in Power Platform, and a manual review gate driven by the registry. It is not automatic in the platform today; it has to be an operating practice.

A Maker-Consumer Separation-of-Duty Model

The final pattern we recommend is an explicit separation between the makers who build agents and the governance approvers who authorize their sharing. In practice this looks like a two-role model:

• Makers build in a designated Power Platform environment, publish to a "staging catalog" that is only visible to a governance review group, and are responsible for the agent's technical quality.
• Approvers are a small, cross-functional group (security, data protection, business sponsor) who evaluate the registry entry, run the acceptance tests, and either promote the agent to a shared catalog or reject it.

The critical rule is that a maker cannot approve their own agent for broad sharing. This is the same separation-of-duty control that appears in change management for any regulated system, and it is the single most effective way to prevent a well-intentioned but risky agent from reaching thousands of users unreviewed.

This model is compatible with self-service enablement — makers still have the freedom to build and iterate — but it gates the moment where an agent goes from personal-productivity to tenant-wide dependency. In regulated industries such as healthcare and financial services, the separation-of-duty gate is not optional; it is a control your auditors will ask about.

What to do next

If your tenant has more than fifty custom agents in circulation and you cannot produce a single-page report showing owner, purpose, knowledge sources, and last review date for each, treat that as a governance gap and close it before it becomes an incident. Our team can stand up the registry, the sharing-surface controls, and the approver operating model as a two-to-three week engagement.

Book a Copilot Studio governance session or start with a shorter readiness assessment to scope your current agent inventory before you invest in tooling.