Agent Governance Is an Org-Design Problem, Not a Policy Document

Most organizations respond to agents showing up in production the same way: get legal, IT, and a business owner in a room, draft a policy, circulate it for sign-off.

Microsoft’s own experience says that response addresses the wrong layer of the problem.

On August 6, 2026, Microsoft’s internal IT organization, Microsoft Digital, published an account of how it governs its own agent population. The headline detail: Microsoft now has visibility into more than 500,000 agents across the company, through a coordination layer called Agent 365. Not a policy. Not a committee. A structural change in who is responsible for what.

That number matters less for its size than for what it reframes. Once an estate is measured in the hundreds of thousands, the binding constraint stops being “what does the policy say.” It becomes “who is actually watching, in which system, using which tool.” A document doesn’t answer that. An org chart does.

What Microsoft Actually Ran Into

Three separate geometric shapes, a cylinder, a cube, and a pyramid, each on its own isolated pedestal with a visible gap between them and no connection linking them

Microsoft’s own account of its prior model is specific. SharePoint administrators managed SharePoint agents. Power Platform administrators managed Copilot Studio agents. Each platform team governed the agents built on its own platform, using its own tools.

Meanwhile, identity, security, and compliance teams handled their own layers — Microsoft Entra, Microsoft Defender, Microsoft Purview — separately. Per Microsoft’s own account, these teams worked “often independently” of the platform administrators and of each other.

That arrangement isn’t a mistake. It’s just what happens when governance grows up one platform at a time. Each team solves its own slice competently. Nobody ever had a reason to build a shared view across all of them, because for a long time there wasn’t an “across all of them” that mattered.

At Microsoft’s scale, that stopped being true. An agent created in one platform, running under an identity issued by another, subject to guardrails set by a third team that has never spoken to either — multiplied across hundreds of thousands of agents — isn’t a governance gap you close with better documentation. It’s a coordination gap you close by naming who does what.

Three Roles, Not One Owner

The same cylinder, cube, and pyramid shapes, each still on its own pedestal, now connected by glowing amber conduits to one shared central plate, all lit in sync

Microsoft’s fix wasn’t to consolidate everything under a single governance owner. It named three distinct administrative roles instead.

AI administrators track the tenant-level inventory: what agents exist, where they came from, and what state they’re in, regardless of which platform created them. Agent Identity administrators own the identity lifecycle — provisioning, credential rotation, and deprovisioning — through Microsoft Entra Agent ID. Security, compliance, and governance teams set the guardrails: risk criteria, approval workflows, and audit requirements, using Entra, Purview, and Defender.

Each role answers a different question. Inventory asks what exists. Identity asks what it’s allowed to authenticate as. Guardrails ask what it’s allowed to do. Those are genuinely separate concerns, and Microsoft’s own materials are careful to say Agent 365 sits on top of the existing platform and identity roles rather than replacing them.

That distinction matters more than it looks like it should. A single “agent governance owner” sounds tidier on an org chart. It also tends to become a bottleneck the moment the estate grows past whatever one team can actually track — a role with a title but no working view into three different tools built for three different jobs.

Here’s an illustrative scenario, not a documented incident, showing what that looks like inside a Dynamics 365 shop specifically. A sales team builds a Copilot Studio agent to draft follow-up emails on open quotes. The Power Platform admin who approved it tracks it inside that one environment. Nobody outside the sales team knows the agent exists.

Months later, the agent starts pulling customer payment history to tailor its follow-ups — a capability nobody outside the sales team reviewed, because nobody outside the sales team knew there was anything to review. The identity the agent runs under was never registered anywhere a security team would think to check. No policy was broken. No rule said this couldn’t happen. The review simply never happened, because no one owned the job of noticing the agent existed in the first place.

Why a Policy Document Doesn’t Fix This

A policy document describes what should happen. It doesn’t say who checks that it’s happening, in which system, on what schedule.

Write a policy stating that every agent needs an approved data-access scope, and you’ve stated an intention. You haven’t said whether the AI administrator’s inventory view, the identity administrator’s Entra records, or the compliance team’s Purview logs is where that scope actually gets verified. Without an answer, the policy sits in a document library while agents keep getting created in whichever tool made that easiest that week.

This is the part most policy exercises skip. Three different functions need to already be pointed at the same inventory, using compatible definitions of what counts as an agent, before a policy has anywhere to attach to. Microsoft’s own experience is that this structural work came first. The policy layer, if it exists at all, comes after.

Put a number on it. An organization with a written AI-use policy, a dozen Copilot Studio agents, a handful of Power Automate flows with agentic steps, and a few custom bot builds can still fail this test completely. The policy exists on paper. Nobody can produce a single list of every agent covered by it. Compliance can’t audit a policy against an inventory that has never been assembled in one place.

What “Start With Visibility” Actually Means

Microsoft’s own stated conclusion is blunt: “Start with visibility, not perfection.” A companion point made earlier in the same piece: avoid creating a bureaucratic choke point. Visibility isn’t the same thing as control. It’s the precondition for control to mean anything.

For an organization without Microsoft’s specific tooling, the translation is straightforward. Visibility means a register — even a manual one — of every agent that exists, regardless of which product created it. Who created it. What identity it runs under. What data and actions it’s authorized to touch.

That register is the org-design starting point. It matters independently of whether an organization runs Agent 365, a Dynamics 365-specific tracking sheet, or something built in-house. The tool is negotiable. The three questions the tool has to answer — what exists, what identity does it hold, what can it do — are not.

For a Dynamics 365 organization without Agent 365, the same three questions map onto tools most IT teams already have. The Power Platform admin center and the Microsoft 365 admin center between them can produce an inventory view, if someone is assigned to actually pull and maintain it. Microsoft Entra already covers identity lifecycle for every other application in the tenant — an agent identity is one more record, not a new discipline. Purview and Defender, or whatever compliance tooling a Dynamics 365 shop already runs, can carry the guardrails role without anything new being purchased. The tooling isn’t the gap. The assignment of who checks each one, on a schedule, is.

The Limits of Copying Microsoft’s Model

The fair objection: not every organization runs at Microsoft’s scale. Standing up three named administrative roles for an estate of a dozen agents in one Dynamics 365 environment is disproportionate. Most organizations don’t need a dedicated Agent Identity administrator as a full-time job.

That objection is correct about headcount. It’s wrong about structure. The three questions — what exists, what can it authenticate as, what can it do — stay distinct even when one person answers all three today. A single IT lead can hold all three roles at a ten-agent shop. What breaks is treating them as one undifferentiated question, because the moment a second person gets added to any one of those three jobs, there’s no defined boundary for what they’re taking over.

The proportionate version isn’t three new hires. It’s three named responsibilities, assigned even when they land on the same desk, so growth doesn’t have to wait for a reorganization to catch up.

Four Questions for Any Estate Size

A short set of questions, regardless of organization size:

Who maintains the inventory of every agent that exists, across every tool that can create one — not just the ones a particular platform team happens to track?
Who owns the lifecycle of an agent’s identity: provisioning, credential rotation, and deprovisioning when a project ends or an agent is retired?
Who sets and reviews the guardrails — data access, approval workflows, audit requirements — that apply across the whole estate, not just the agents running in one product?
Do the answers to those three questions point to the same person or team today? If they don’t, has anyone connected them, or are they three separate views that have simply never been compared?

That last question is usually where the gap actually is. Not in any one team’s competence — in the absence of a reason, until now, for the three views to be reconciled at all.

This question sits apart from two others already raised about agent governance in Dynamics 365. One asks whether a single agent-as-control answers to finance and IT governance at once, with neither side owning the combined thing — a process-interface problem between two functions. Another asks whether the specific security role an agent inherits already carries a dormant conflict of duties — a problem inside the content of one role. This one sits above both. It’s about whether anyone has assigned responsibility for seeing the whole estate at all, before either of those questions can even be asked with a straight answer.

DAX Software Solutions helps Dynamics 365 organizations build that inventory view and assign the three functions — inventory, identity, and guardrails — before an agent estate outgrows whatever informal tracking got it this far. Get in touch if your organization is scaling agent deployments and hasn’t yet named who owns each of those three jobs.