Part 5 of 7 · Governance Debt
The first four parts of this series were about content — how the estate grew without a design, how AI made it answerable, how oversharing became exposure, how duplicated and obsolete files became confident wrong answers. All of it was about the nouns in your tenant: files, sites, permissions, links.
This part is about the verbs. The things that read all of that content and act on it. Your agents.
And here is the uncomfortable symmetry: everything that made your content ungovernable is now making your agents ungovernable, one layer up. Agents accreted the same way sites did — through self-service, by makers, one at a time, to solve a real local problem, with no central register and no review gate. The sprawl was a feature, right up until you needed to answer a question about it. Agent governance isn’t a new discipline. It’s the governance debt you already have, wearing a newer, more capable face.
Same debt, one layer up
Think about what you learned to ask about a SharePoint site: Who created it? Who owns it now? What can it reach? Has anyone looked at it since it was made? Those are exactly the questions you cannot currently answer about the agents in your tenant — and there are more of them than you think, in more places than you’d look.
Because “agents” in a Microsoft estate don’t live in one place. They live across at least three separate control planes — Copilot Studio and the broader Power Platform, the Microsoft 365 Copilot surface, and Azure AI Foundry — each with its own admin experience, its own identity model, and its own idea of what an “agent” even is. No single admin screen shows all of them. A governance review scoped to “the Copilot agents” is auditing one plane of three.
We won’t re-walk the mechanics of those planes here; we’ve already done that in detail in Your Microsoft 365 tenant has AI agents you can’t see, which is the deep dive on the three-plane problem and what an honest cross-plane inventory actually has to resolve. Read that for the how. This post is about the why it feels so familiar — because it’s the same story you’ve been reading since part one.
What we found when we counted
When we scanned a real tenant and actually counted, the Power Platform side reported dozens of Copilot Studio agents scattered across roughly nineteen environments — default environments, personal-productivity environments, per-maker dev environments, almost none of it in the one “production” environment a governance team would think to check. A separate scan of the same organization’s Azure estate surfaced a handful of Azure AI Foundry agents — pro-code agents wired to frontier models — that appeared in no Microsoft 365 admin surface at all. Same company, same data, two disjoint universes of agent, and one governance team with a view into neither in full.
None of that was negligence. Nobody decided to build an ungoverned agent fleet. Each agent was one person solving one problem with the self-service tools they were handed — which is precisely how you got 235 sites and a decade of forgotten sharing links, too. The default produced the sprawl. It always does.
An agent inherits the exact state of your estate
Here’s where the earlier parts of the series come due. An agent is grounded on content — and it inherits whatever state that content is in. Point a maker-built agent at a site that’s overshared to “Everyone” (part 3) and its answers reach as far as that grant does. Ground it on a document library full of five-copies-of-the-same-policy ROT (part 4) and it will cite the 2019 draft with the same confidence as the 2026 final. The agent doesn’t fix the debt underneath it. It operationalizes it, at machine speed, behind a friendly chat box, with a citation attached.
So an ungoverned agent isn’t one risk. It’s a multiplier on every unresolved problem in the four posts before this one — and you can’t even enumerate the multipliers, because you can’t see all the agents.
Microsoft knows the surface is fragmented
To its credit, Microsoft is building for exactly this. The Copilot Control System is the framework it points to for securing, managing, and measuring Copilot and agents, explicitly spanning Copilot Studio and the agents your organization builds and publishes. The Microsoft 365 admin center now manages agents through an agent registry — you can see shared agents with their creator, creation date, and host products, and block ones deemed noncompliant. And Microsoft Agent 365 is positioned as a control plane meant to govern agents “regardless of where these agents are built or acquired” — an explicit admission that they’re currently built and acquired in a lot of disconnected places.
Two honest caveats. First, this tooling is inventory-first: it’s very good at telling you an agent exists and much quieter on whether its configuration has drifted since anyone approved it. Second, the Azure Foundry plane still lives under Azure RBAC, and Foundry can publish agents into Microsoft 365 and Teams — the reach flows across the boundary even when your governance visibility doesn’t.
The register you don’t have yet
Treat agents as a first-class asset class, alongside users, devices, and apps. They have identity, permissions, data access, a creator, and a lifecycle — they deserve the same register you’d never dream of running a tenant without for user accounts. Any single admin center is a partial view by construction; the whole-estate number has to come from all three planes at once, and it has to say what it couldn’t see rather than reporting its blind spots as zeros.
But notice the question hiding inside “who owns this agent?” It’s the same question hiding inside “who owns this site,” “who approved this access,” and “who last confirmed any of it was still needed.” That’s not an inventory question anymore. That’s accountability — and it’s where this series goes next.