Agents
Govern every AI agent in your tenant - what each can actually read across files, sites, users, and email, who deployed it, and how to constrain it before rollout.
Agents
The Agents screen answers the question that decides whether enterprise AI is an asset or an incident: "What can our AI agents actually reach - and who decided that?" Agents ship with vendor products, get built by employees in an afternoon, and inherit access nobody consciously granted. 1Security unifies every agent - Copilot, Entra, Azure, and third-party - into one governed inventory with its true data reach quantified. See the Agents guide for how the sources fit together.
What You Can Achieve
Take a census of your AI workforce
Every agent instance in the tenant - vendor-shipped, employee-built, or bundled with a product you licensed - with who created it and whether its account is even enabled.
Quantify reach before you trust
For each agent, the number of users, files, sites, and emails it can actually access, and whether sensitive data is within reach. Guardrail decisions made on numbers, not manifests.
Govern blueprints, not just instances
Agents are stamped out of blueprints. Review the template once - publisher verification, declared permissions, how many instances exist - instead of chasing each copy.
Set guardrails that stick
Block specific permissions for agents and verify the block holds. Safe AI rollout means deciding what agents can't read before employees start asking them questions.
Agents and Blueprints
The screen splits into two tabs because AI governance has two layers:
- Agents - deployed instances doing work in your tenant today. This is where reach, activity, and permissions are real.
- Blueprints - the templates agents are created from, with their publisher, verification status, declared permissions, and how many permissions cascade down to instances. One unverified blueprint can be the parent of fifty agents.
How Agents Reach Your Files
The critical classification on this screen is the file access channel - the mechanism, not the marketing, of an agent's data access:
- Tenant-wide - application-level access to files across the organization. The highest-stakes category; treat each entry as a standing decision.
- Admin-consent delegated - reads files as whichever user is interacting with it, approved for everyone by an admin.
- Explicit grant - scoped access to specific resources. This is what deliberate agent governance looks like.
- None - no file path today.
Email access follows the same logic (tenant-wide, scoped, or none), and every agent's permissions are broken into direct, inherited, and blocked - so you can see both what an agent was given and what you've explicitly denied it.
Agents also declare knowledge sources (SharePoint, OneDrive, Teams, Email, Website, Graph connectors, Dataverse, People, Meetings) and capabilities (web search, code interpreter, image generation, actions). An agent that can read email and take actions deserves a different review than one that summarizes a website.
The Agent List
Rows quantify each agent's footprint: blueprint, creator, account status, file access channel, reach counts across users, files, sites, and emails, a sensitive-data flag, and the direct / inherited / blocked permission split. Click an agent to open its drawer - the Files, Sites, Users, and Emails tabs show exactly what it can reach and through which channel or knowledge source, turning "it has Sites.Read.All" into a concrete list of what that means.
Filters narrow by status, file and email access channels, permission risk (blocked / inherited / direct), knowledge source types, capabilities, and blueprint; the Blueprints tab filters by publisher verification and whether instances exist.
Investigative Patterns
The pre-rollout gate: filter file access tenant-wide + sensitive data within reach. These are the agents to constrain first - every one of them can surface regulated content to anyone who chats with it.
- Supply-chain check - in Blueprints, filter unverified publishers + with agents: unvetted third-party templates already running in your tenant.
- Read-and-act risk - agents with the actions capability + email access: the profile where prompt injection stops being theoretical, because the agent can both ingest untrusted content and do something about it.
- Orphaned AI - agents whose creator has left or whose account is disabled but that still hold permissions: decommission them like you would a service account.
Locations
See every place your Microsoft 365 activity really comes from - offices, home networks, VPNs, Tor and datacenters - and whether your Conditional Access rules actually govern them.
Users
Every identity in the tenant - employees, guests, and the accounts nobody has signed into for a year - with what each one can reach, what it did, and whether it should still exist.