Microsoft 365 AI agent inventory
Someone built an agent in an afternoon. It can read the finance site.
Agents ship with vendor products, get built by employees in Copilot Studio in an afternoon, and inherit whatever their builder or blueprint could reach - nobody consciously granted it. In a typical tenant starting a Copilot rollout we already find dozens of agents, and a handful of them can read hundreds of thousands of files. 1Security puts every Copilot, Entra and Foundry agent in one Microsoft 365 AI agent inventory and counts, per agent, the users, files, sites and mailboxes it can actually reach.
- 4reach counts per agent - the users, files, sites and emails it can actually access
- 3agent sources brought into one list - Copilot Studio, Entra Agent ID, Azure AI Foundry
- 9knowledge source types resolved to real sites and mailboxes - SharePoint, OneDrive, Teams, email, websites, Graph connectors, Dataverse, people, meetings
The problem
A new workforce, onboarded by nobody
Agents are identities. Nobody hired them, nobody reviews them, and they keep their permissions until someone notices.
The person who builds an agent in Copilot Studio is thinking about a task, not about access control. The agent inherits whatever the builder could reach or whatever its blueprint declared, and the gap between "I made a small assistant" and "this thing can read the finance site" is invisible from inside the tool that created it.
Reading the manifest does not close that gap. A declared permission like Sites.Read.All names a category, not a consequence. Governance needs the list: which sites, which files, how many carry regulated data, and through which channel the access arrives. Agents arrive from several places - Copilot Studio, Entra Agent ID, Azure AI Foundry, vendor products - each with its own model and tags. 1Security brings them into one list and adds the reach.
1Security resolves it for every agent in the tenant, whether it came from Copilot Studio, Agent Builder, Entra Agent ID, Foundry or a vendor product, and keeps the blueprints in view - so one review of a template covers the fifty agents stamped out of it.
What you get
Every agent, with what it can actually read
Instances are where reach is real. Blueprints are where one review covers many agents.
The census
Every agent instance in the tenant - vendor-shipped, employee-built or bundled with a licensed product - with its creator, its blueprint and whether its account is even enabled. Usually more than anyone on the security team expected.
Reach in numbers
Users, files, sites and emails each agent can access, plus a sensitive-data flag. Sort by files in reach and a handful of agents account for most of the exposure.
File access channel
Tenant-wide, admin-consent delegated, explicit grant or none; email access classified the same way. The mechanism of the access, not the marketing.
Blueprints as a governed object
Publisher, verification status, declared permissions and how many cascade to instances. One unverified blueprint can be the parent of fifty agents.
Knowledge sources and capabilities
SharePoint, OneDrive, Teams, email, websites, Graph connectors, Dataverse, people and meetings resolved to real sites and mailboxes - plus whether the agent can search the web, run code, generate images or take actions.
Direct, inherited, blocked
Every atomic permission with its source, and the "blocked for agents" flag - so you can see what an agent was given, what it picked up, and what you explicitly denied it.
How deep it goes
From "it has Sites.Read.All" to a list of sites
Open an agent and the Files, Sites, Users and Emails tabs show exactly what it can reach and through which channel or knowledge source.
The pre-rollout gate: filter file access tenant-wide + sensitive data within reach. Every agent on that list can quote regulated content to anyone who chats with it. In a mid-size tenant it is usually a short list - and the whole point is to see it before employees start asking questions.
The supply-chain check: in Blueprints, filter unverified publishers + with agents. These are unvetted third-party templates already running in your tenant, and the cascading-permissions count tells you how much each one hands down.
Read-and-act risk: agents with the actions capability + email access. That combination is where prompt injection stops being theoretical - the agent can ingest untrusted content and then do something about it. It deserves a different review from a website summariser.
In practice
How a governed rollout sequences
Reach first, guardrails second, enablement third. The order matters more than the tooling.
- 01
Take the census
Open Agents. The list lands with creator, blueprint, status and reach counts - typically including agents nobody on the security team knew existed.
- 02
Sort by files in reach
Sort descending, add the sensitive-data filter. In most tenants five to ten agents hold most of the exposure; those are the first review.
- 03
Fix the data, not just the agent
Most agent over-reach is inherited oversharing. Expire the anyone links and trim the site permissions underneath, and every agent that inherits from them is constrained at once.
- 04
Block, then verify
Set the permissions agents may not hold and confirm the block shows on the row next to direct and inherited permissions. A guardrail you have not verified is a policy document.
What 1Security adds
One population, one list, with reach
Agents are created in several places. 1Security governs them as one population and adds what each one can actually read.
- Copilot, Entra Agent ID, Azure AI Foundry and third-party agents in one inventory
- The concrete files and sites behind a declared permission scope, counted
- Whether sensitive data sits inside the reach of each agent
- Blueprints with publisher verification and the permissions that cascade to instances
- Direct, inherited and blocked permissions shown separately
- Knowledge sources declared per agent, resolved to real sites and mailboxes
- Agents whose creator has left or whose account is disabled but which still hold permissions
- Capability flags - web search, code interpreter, image generation, actions
Scale
Agents multiply faster than reviews
A blueprint is copied in seconds. Governance that works per instance loses immediately, which is why the template layer is a governed object here rather than an afterthought. Reach counts come from the same permission graph that already resolves users and apps - the one that runs on tenants with 500M+ files.
- 2layers governed separately - agent instances and the blueprints they come from
- 1Agent 365 license on the connecting admin unlocks the Copilot agent catalog; Entra agents need nothing extra
- 0write permissions needed for the census - blocks are a deliberate second step
Related
Where this fits
Agent reach is inherited reach. Almost every finding on this screen resolves in the file and site permissions underneath it, which is why the AI conversation and the oversharing conversation are the same conversation.
Copilot security
What Microsoft 365 Copilot itself would read - the rollout view of the same problem.
See Copilot →App governance
The other non-human identities: OAuth apps, add-ins and managed identities, with how each reaches data.
See apps →File permissions
The layer an agent inherits from, and the fastest place to constrain it.
See files →
FAQ
Questions teams ask first
Which agents are covered?
Copilot agents built in Copilot Studio or Agent Builder, Entra Agent ID agents - including Azure AI Foundry builds and the earlier generation that exist as tagged service principals - and vendor-shipped agents that arrive with a licensed product. The inventory covers them wherever they were created.
Do we need a special license?
Entra-backend agents need nothing beyond the standard read-only connection. The Copilot agent catalog is read with an Agent 365 license - one license, about $15 per user per month standalone, on the admin account that connects 1Security is enough. Without it, 1Security says so plainly and still scans the Entra side.
What is a blueprint?
The template an agent instance is stamped out of. Reviewing it once - publisher, verification, declared permissions, how many permissions cascade - covers every instance created from it, which is the only way agent governance keeps up with agent creation.
Can I actually stop an agent from reading something?
Yes. Permissions can be blocked for agents, and the block is verifiable on the agent row next to its direct and inherited permissions. The more durable fix is removing the underlying oversharing, because that constrains every agent at once.
What happens to agents whose creator has left?
They keep working. Orphaned agents are their own filter, and the right treatment is the one you would give an orphaned service account: identify an owner or decommission it - behind the same review window as every other action.
Take the census before the rollout.
Connect read-only and every agent in the tenant arrives with its reach attached the same day - including the ones built in an afternoon.
Or find out what an agent can read from a generated answer.