Your Microsoft 365 tenant has AI agents you can’t see

Ask an M365 admin how many AI agents run in their estate and you’ll usually get one of two answers: the count of Copilot licenses, or a shrug. Both are wrong, because “agents” in a Microsoft tenant now live on at least three separate control planes — and no single admin screen shows all of them.

We know because we scanned a real tenant and counted. The Power Platform side reported dozens of Copilot Studio bots across ~19 environments. A separate scan of the same organization’s Azure estate found a handful of Azure AI Foundry agents — production agents wired to frontier models — that appeared in no Microsoft 365 admin surface at all. Same company, same data, two different universes of AI agent, one of which the M365 governance team had no view into whatsoever.

The three planes where agents live

1. Copilot Studio / Power Platform. Copilot Studio agents inherit the Power Platform’s environment model, DLP policies, and admin center, and Microsoft’s Copilot Studio security and governance guidance is genuinely substantive here. But the operative word is environments — plural. Agents accumulate in default environments, dev environments, and personal-productivity environments, built by makers, not IT. If your governance review covers “the production environment,” you are auditing the tip.

2. Microsoft 365 / Copilot Control System. Declarative agents, agents installed from the store, SharePoint agents. The Copilot Control System and the M365 admin center’s agent inventory are Microsoft’s answer for this plane — Microsoft-built, partner-built, and line-of-business agents, with filters for orphaned agents (“missing owner”) that tell you Microsoft already expects agent abandonment at scale.

3. Azure AI Foundry. Pro-code agents built in Foundry Agent Service live under Azure subscriptions, governed by Azure RBAC — a plane most M365 governance teams don’t even have read access to. These are frequently the most capable agents in the estate: custom instructions, tool access, connected data. In our scan, enumerating them required a data-plane RBAC role that nobody had thought to grant, because nobody had thought to look. Until the role was granted, the API cheerfully returned an empty list — the agents existed, the inventory said zero.

Microsoft knows this fragmentation is a problem; the emerging Agent 365 work in the M365 admin center is explicitly aimed at a cross-plane agent registry. It is early, and it is inventory-first, not risk-first.

What “agent inventory” should actually mean

An inventory that lists agent names is a phone book. A governance-grade inventory answers, per agent:

• Existence & ownership — who created it, who owns it now, is the owner still employed? (Orphaned agents are common enough that Microsoft ships a filter for them.)
• Identity & permissions — what does it authenticate as, and what can that identity touch?
• Model & instructions — which model, what system prompt, and has the configuration drifted since someone last reviewed it? Agent definitions change silently; a point-in-time approval is worthless without drift detection.
• Tools & connections — what APIs, connectors, and data sources can it call? An agent with no tools and an agent with a SQL connection are different risk classes entirely.
• Grounding data — what content can it read, and does that content carry sensitivity labels the agent’s audience shouldn’t traverse?
• Reach — who can invoke it: one maker, a team, or every user in the tenant?

Questions a CISO should ask this quarter

1. How many AI agents exist across all three planes — and who produced that number, from what source, dated when?
2. How many have no current owner?
3. Which agents can act (send, write, execute) rather than just answer?
4. Who is allowed to create an agent, in which environments, and what review happens before one reaches real users?
5. When an agent’s configuration changes, does anyone find out?
6. If the answer to #1 came from a tool: does that tool report what it couldn’t see (subscriptions it lacked access to, environments it couldn’t read), or does it present its blind spots as zeros?

That last question matters more than it looks. In our own scanning we’ve watched an agent inventory read “0 agents” purely because of a missing permission — the difference between “you have no agents” and “I can’t see your agents” is the difference between assurance and false assurance.

Practitioner takeaways

• Treat agents as a first-class asset class, alongside users, devices, and apps. They have identity, permissions, data access, and lifecycle — they deserve the same register.
• Inventory all three planes; any single admin center is a partial view by construction.
• Insist on ownership and drift tracking, not just enumeration.
• Grant your governance tooling explicit read access to the Foundry/Azure plane — the default state is blindness that looks like zero.

Polaris Governance builds exactly this: a unified inventory and risk view across the agentic Microsoft 365 estate — Copilot Studio, M365 agents, and Azure AI Foundry — with ownership, configuration drift, and honest coverage reporting. Sources: Copilot Control System overview, M365 agents admin guide, Copilot Studio security & governance, Foundry Agent Service overview, Agent 365 overview.