What Microsoft's agent governance covers, and what it doesn't

If you administer a Power Platform tenant, the last two years delivered more governance surface for agents than most platforms get in a decade: a tenant-wide inventory, mandatory data policies, first-class agent identities, audit events, threat detection. If you are not using what your licenses already include, start there.

This guide is about the line those tools stop at, because it is a structural line rather than a missing feature, and knowing where it sits changes how you audit an agent. The short version: everything observational watches interactions, everything structural stops at the connector, and nothing computes what an agent can actually reach in Dataverse.

The four planes Microsoft shipped

The stack sorts into four planes, and each is genuinely good at its own job.

• The Power Platform admin center's agent inventory lists every agent in the tenant with its owner, publish state, authentication mode, sharing counts, and per-connector operation detail, including whether each connection is user-provided or maker-provided. It is queryable by API and it is free.
• Data policies for agents are mandatory tenant-wide, and can block connector classes, no-authentication chat, HTTP nodes and knowledge-source categories at design and publish time. Managed Environments adds sharing limits.
• New Copilot Studio agents get an Entra Agent ID, and Dataverse can now add an agent as a first-class security principal with its own security roles, in the same systemuser machinery as everything else.
• Purview ships audit events for agent authoring and, with the right licensing, Sentinel and Defender watch agent interactions for jailbreaks, prompt injection and exfiltration patterns.

Every item on that list governs the agent as a unit, the connector as a class, or the conversation as an event. None of them opens the agent up and resolves what its tools are defined to do.

The three questions the stack does not answer

Put the same audit questions to each plane that you would put to a plugin, an integration account, or a Power Pages site, and the pattern shows immediately.

Microsoft knows this. In early 2026 its own security team published a list of the ten most common Copilot Studio agent misconfigurations, and the list reads as a description of the gap: administrators cannot audit HTTP endpoints, cannot see over-permissioned connections, cannot see inside knowledge sources, and get no risk scoring. Those are structural observations about the admin surface, from the vendor, and they are worth taking at face value.

Why the ceiling is structural

It would be easy to read the gap as backlog, but the boundary follows from what each plane is built on, which is why a new release keeps landing on the same side of it.

Enforcement is connector-class-based because policy evaluation happens at design and publish time, when the connector is the abstraction available: which table a Dataverse tool will touch is decided by the tool's configuration and, in the common case Microsoft's own samples teach, by the caller at run time. A policy engine that stops at the connector is not lazy; it is honest about what is knowable at the moment it runs. The inventory has the same shape: it reports what the platform declares about a published agent, and the declaration stops at connector operations.

The observability plane is interaction-centric because that is what audit infrastructure is: a record of events. Events tell you a property changed and who changed it. Turning that into “what is different between March and June” means replaying every event against a reconstructed state, inside a retention window, yourself.

Answering the three questions takes a different kind of system: one that parses the agent's stored configuration into dependency edges, resolves identities through the security model, and keeps scan-over-scan state. That is a graph, not an inventory, and none of the four planes is built to become one.

The license and cloud fine print

Two practical constraints sit on top of the structural one. Meaningful coverage across the four planes is not one license: the interaction-security half in particular assembles from E5-class compliance licensing, pay-as-you-go Purview, a Sentinel workspace, and the Agent 365 gate that agent-specific protection moved behind in mid-2026. Small and mid-size tenants routinely hold none of those.

And the story is commercial-cloud-first. The Purview audit pipeline for Copilot Studio lists a non-FedRAMP tenant as a prerequisite, and the newer inventory, agent-identity and agent-security capabilities have no announced availability in GCC, GCC High or DoD. An agency can build agents in those clouds; the governance stack described above largely does not follow them there. If your tenant is a government cloud, the manual method below is not a fallback, it is the method.

Auditing an agent by hand

All of this is auditable today, without buying anything, because the configuration lives in Dataverse tables you can read.

Start with the tenant inventory

Export the admin center's agent inventory and sort by authentication mode and sharing first: an agent with no authentication, or shared tenant-wide, is worth your attention before any deep dive. Note which connections are maker-provided; each of those tools runs as its author, not as the person chatting.

Then go deeper with the Power CAT kit

Microsoft's free Copilot Studio Kit derives a much richer inventory by reading the bot and botcomponent tables directly, and its review tool scores agents against a set of documented anti-patterns. It is unsupported tooling, and it is also the honest proof that this audit is a metadata read: everything it derives comes from rows your own environment already holds.

Then read what the platform stores

• An agent's tools and topics are rows in botcomponent; Dataverse knowledge configuration lives in the dvtablesearch family, down to which columns are indexed. Reading them tells you what a tool names in its configuration; where a tool takes its table from the caller, note that you cannot enumerate its reach, and treat that as a review finding in itself.
• If the agent has a Dataverse agent user, open its security roles and walk them the way you would for an integration account: privilege by privilege, scope by scope. This is exactly the exercise from the integration account guide, applied to a newer kind of principal.
• For every maker-provided connection, look up the maker's own roles, because that is the identity the tool executes under. If the maker holds System Customizer, so does the tool.

The limits of the manual method are the familiar ones: it is per-agent rather than an inventory, effective reach across roles, teams and column security does not combine by hand at any scale, and everything you conclude is true on the day you did it.

Where Pathix comes in

Pathix reads the same rows the manual method reads, into the graph it already builds for plugins, flows and Power Pages: every agent tool resolved to the table its definition pins, with whose connection it is set to run on, and a tool whose table is left for the agent to choose kept visible as a capability rather than dropped. Knowledge exposure is read at column level where the platform enumerates columns and at table level where it does not, and crossed with sensitivity and with how each agent admits callers. Agent identities that hold roles are counted, and what they can reach follows their roles through the same effective-permissions engine as any other principal. Every estate component lands in the scan-over-scan ledger. Metadata only, and never conversations: transcripts and run history are customer content and stay outside the boundary that keeps record values out of everything else.

The capability page shows what that looks like on the sample environment, including the bounds: What does your AI's configuration put in reach?