Copilot agents and Agent Store governance

Microsoft 365 Copilot stopped being one assistant some time ago. It's now a platform that runs agents — scoped, purpose-built assistants that anyone from Microsoft to an ISV to the person two desks over can create — and the Agent Store is how they spread through your tenant. That makes agent governance a real admin discipline in 2026, and one where the controls exist but are scattered across three admin centers and a set of defaults worth checking rather than trusting.

What a Copilot agent is

An agent is Copilot with a job description. Under the hood there are two architectures:

• Declarative agents ride on the Copilot infrastructure itself: same foundation models, same orchestration, but with custom instructions, a narrowed knowledge scope (specific SharePoint sites, connectors, or uploaded files), and optionally actions that call APIs. The "Researcher" and "Analyst" agents Microsoft ships, most Store agents, and everything users build with the lightweight agent builder are this type.
• Custom engine agents bring their own orchestration and models — built in Copilot Studio or pro-code frameworks — and surface inside Teams and the Microsoft 365 Copilot app. More powerful, more to review, because the reasoning happens outside the Copilot trust boundary.

The practical governance point: an agent is software with a data scope and (sometimes) write actions, published under an identity. Evaluate it like an app, not like a chat setting.

The Agent Store: distribution

The Agent Store is the in-product catalogue — in the Copilot app and Teams — where users discover and install agents from three origins: Microsoft-built, ISV-published (validated by Microsoft before listing), and your own organisation's (shared by makers or deployed by admins). Store listing gets an ISV through Microsoft's validation, but validation is a baseline — it does not mean the agent's data handling fits your policies, any more than an app existing in the Teams app store meant you wanted it deployed tenant-wide.

Because agents are packaged and distributed through the same plumbing as Teams/Microsoft 365 apps, the familiar app-governance machinery applies — which is good news, since you may already run this muscle.

The tenant controls, admin center by admin center

Microsoft 365 admin center → Integrated apps is the main lever. From there you can allow or block individual agents (Microsoft, ISV, or internal), deploy an agent to everyone or to specific groups, and set the default posture for whether users can install Store agents at all. Blocked means it disappears from the Store for your users; deployed means it shows up pre-installed. Treat the available/blocked lists as policy, not as a browse-once page.

Who can build and share is governed elsewhere. The lightweight agent builder (the "make your own agent" experience inside Copilot) can be switched off or scoped by group via the Copilot admin settings. Copilot Studio agents are Power Platform citizens: environments, maker security roles, and DLP policies (which connectors an agent may combine) decide who can build what against which data, and pay-as-you-go or message-pack capacity billing decides what it costs. If you already run Power Platform governance — default environment locked down, named maker environments, DLP by environment — Copilot Studio agents inherit that discipline for free. If you don't, agents are the reason to start; there's a sister-site angle here too, since the same Copilot Studio governance carries over to Dynamics 365.

A review workflow for internal agents comes almost free: agents shared beyond a team or submitted for org-wide listing land as approval requests for the admin (the same submit-and-approve flow as custom Teams apps). Put a named owner and a rubric on it: what data does the agent ground on, does it take actions or only answer, who maintains it, and does it duplicate something already approved. Approve narrowly — to the requesting group first, org-wide only when there's a reason.

The data question — where the risk actually lives

Agents don't bypass permissions: a declarative agent grounding on SharePoint retrieves only what the asking user can already access, and Purview sensitivity labels and audit continue to apply. The honest risk is different — agents are oversharing amplifiers. Every tenant has sites shared too broadly and files with "everyone" links that stayed obscure only because nobody searched for them. An agent scoped to broad content turns that latent exposure into fluent answers. The prerequisite for agent rollout is the same one as for Copilot itself: SharePoint sharing hygiene, Restricted SharePoint Search or Restricted Content Discovery for the worst sites, and label-driven exclusions — done before enthusiasm, not after the first incident.

Custom engine agents and agents with actions deserve a harder look: their calls leave the Microsoft 365 boundary on terms defined by the builder, so review them as third-party integrations with data egress, not as chat features.

Honest limits

Be clear-eyed about what this governance surface doesn't give you:

• It's fragmented. Allow/block in the Microsoft 365 admin center, maker and DLP control in Power Platform, Copilot settings in a third place. There is no single pane, and the surfaces keep moving as Microsoft ships.
• Visibility is shallow. You can see which agents exist and who uses them; auditing what an agent retrieved and why is far coarser than security teams want, especially for custom engines.
• Validation ≠ vetting. Store checks are a floor. Your review of an ISV agent's data flows is still your job.
• Sprawl is the steady state. Easy creation means duplicate, abandoned, and owner-less agents within months. Without a periodic inventory-and-retire pass, the Store becomes the new "SharePoint site sprawl."
• Metering surprises. Copilot Studio agent consumption is billed by messages/capacity; a popular agent is a cost centre nobody forecast.

A sensible starting posture

Set Store installs to allowed-with-review rather than wide open; block nothing reflexively, but deploy deliberately. Turn the agent builder on for a pilot population, not the tenant. Lock the Power Platform default environment down and give makers a real environment with DLP. Stand up the approval workflow with a named owner and a written rubric. And do the sharing-hygiene work first — every agent problem that makes headlines is an oversharing problem wearing an AI costume.

Agents are genuinely useful, and they're coming through the door either way — governed distribution is what makes the difference between a capability and a mess.