Microsoft Agent 365 Security Guide: Governing AI Agents at Scale
Agent 365 is the centralized control plane — the single admin surface where you observe, govern, and secure AI agents across your Microsoft 365 tenant. It does not build agents and it does not run agents. Its job is to make sure every agent in your organization has an identity, a sponsor, an access policy, and an audit trail.
Who this is for: IT administrators, security engineers, and identity architects responsible for deploying or evaluating Agent 365. You should be comfortable navigating the M365 admin center and Entra ID. No prior experience with AI agent governance is required.
This guide walks through the full setup, from registry configuration to multi-cloud sync, with the exact admin center paths, license requirements, and known gaps you need to plan around.
Prerequisites
Confirm these are in place before you start. The first two are hard requirements; the rest are strongly recommended for full capability.
-
Agent 365 LicenseAt least one user licensed with Agent 365 ($15/user/month standalone or included in M365 E7 at $99/user/month). Covers anyone who interacts with, owns, manages, or sponsors an Agent 365-managed agent.Required
-
Global Administrator RoleRequired for initial Agent 365 setup and registry configuration in the M365 admin center.Required
-
Entra ID P1 or P2 (or Entra Suite)Enables Conditional Access — rule-based policies that control who can sign in and under what conditions (device compliance, location, MFA). P2 adds Privileged Identity Management (PIM), which provides time-limited, approval-gated elevation for sponsor oversight roles.Recommended
-
Microsoft Purview (DLP + Compliance)Required for Data Loss Prevention (DLP) policies that block sensitive data from leaking through agent interactions. Also unlocks DSPM for AI (Data Security Posture Management — a dashboard that shows which agents are accessing sensitive data and how), eDiscovery (legal hold and search of agent conversations), and Communication Compliance monitoring.Recommended
-
Entra ID Governance LicenseRequired specifically for lifecycle workflows (Step 3) — sponsor transfer on employee departure, orphaned agent flagging, and co-sponsor notification.Recommended
-
Microsoft Defender for Cloud AppsEnables shadow AI discovery — detecting unauthorized agent traffic and locally installed agent software on managed devices. Used alongside Intune for endpoint-level enforcement.Recommended
-
Microsoft IntuneRequired for blocking or managing locally installed agent binaries on managed Windows devices. Without Intune, shadow AI discovery detects network traffic but cannot enforce device-level policies.Recommended
Your Progress
Track your setup as you work through each step. Click a step to mark it complete. Your progress is saved in your browser.
- Configure Agent Registry
- Set Up Identity Blueprints
- Configure Lifecycle Workflows
- Enable Shadow AI Discovery
- Govern MCP Servers
- Connect Multi-Cloud Registry Sync
- Set Up Monitoring and Compliance
- Review Pricing and Budget Plan
- Document Limitations and Gaps
The Three Pillars of Agent 365
Everything Agent 365 does falls into one of three categories. Understanding the boundaries is critical because the governance license covers these pillars only. Execution costs (actually running agents and processing queries) are billed separately through Copilot Studio (Microsoft's no-code/low-code agent builder) or Azure AI Foundry (the developer platform for building custom AI agents and models on Azure).
Observe
The observe pillar provides visibility into every agent touching your tenant. The Agent Registry is the single source of truth: it catalogs first-party Microsoft agents, third-party agents discovered through Defender and Intune, and (in preview) agents synced from AWS Bedrock and Google Vertex AI. Shadow AI discovery surfaces local agents running on Windows endpoints that IT never approved. Analytics dashboards track agent usage patterns, data access, and interaction volume.
Govern
Governance puts guardrails around the agent lifecycle. Every agent gets an identity blueprint that defines its authentication method, permissions, and Conditional Access policies. The sponsor model ties each agent to a responsible human. Lifecycle workflows automate what happens when a sponsor leaves the organization: transfer sponsorship to a co-sponsor, notify the security team, or deactivate the agent. Access control determines which users can interact with which agents and through which channels.
Secure
The security pillar integrates with the products you already have. Entra provides identity and Conditional Access. Purview extends DLP policies to agent interactions and provides DSPM for AI. Defender handles runtime threat protection and detection/response. The security posture management and detection/response features are still in preview at GA, but Purview compliance extensions (Audit, eDiscovery, Communication Compliance) are generally available.
Step 1: Configure the Agent Registry
The registry is your single pane of glass for every agent in the tenant. Before you configure anything else, you need to see what is already running.
Before you start: If you do not see the Agents navigation item in the M365 admin center, verify that at least one user in your tenant is licensed for Agent 365. The Agents section only appears after the first license is assigned and the tenant provisioning completes (usually within 15 minutes).
Navigate to the Registry
Open the M365 admin center and go to Agents > All Agents. This view shows every agent that has registered with your tenant, grouped by source (Copilot Studio, Azure AI Foundry, third-party connectors, and shadow agents discovered by Defender).
Understand Blueprints
Each agent in the registry is backed by a blueprint. Blueprints are IT-approved templates that define the agent's authentication method, permission boundaries, and Conditional Access policies. The credentials live on the blueprint, not on individual agent instances. When a user activates an agent, they get an instance of the blueprint with the policies already attached.
Activate and Configure Access
For each blueprint you want to make available:
- Review the default permissions and confirm they match your organization's least-privilege policy
- Set the user scope: all users, specific security groups, or individual users
- Enable or disable the agent's ability to call external MCP servers (more on this in Step 5)
- Verify the authentication method matches your Entra Conditional Access requirements
Tip: Start with a pilot group. Assign a small security group to two or three agent blueprints, monitor usage for a week, then expand. Do not activate everything at once.
Verify
Navigate to Agents > All Agents and confirm you see at least one agent listed. Filter by source type (Copilot Studio, third-party, Defender-discovered). If no agents appear, verify that an Agent 365 license is assigned and that at least one agent-capable workload (Copilot Studio, SharePoint, or a third-party connector) is active in the tenant.
Step 2: Set Up Identity Blueprints
Every managed agent needs an identity in Entra. Agent 365 uses Entra Agent ID to give agents first-class identities that follow the same Conditional Access and least-privilege policies as human users.
Two Authentication Models
Blueprints support two authentication modes, and the distinction matters for your security posture:
| Model | How It Works | Use Case | GA Status |
|---|---|---|---|
| On-Behalf-Of (OBO) | Agent acts with the authenticated user's identity and permissions — if the user cannot access a SharePoint site, neither can the agent. Interactive session required. | Copilot assistants, user-facing chatbots, co-authoring agents | GA |
| Client Credentials | Agent authenticates with its own identity. No user session needed. Runs autonomously. | Background processing agents, scheduled automation, pipeline agents | Frontier Preview (early access, not production-ready) |
The Sponsor Model
Every agent identity blueprint must have a sponsor: a named human who is accountable for that agent's behavior. The sponsor is responsible for reviewing the agent's permissions, responding to security alerts, and approving changes to the blueprint. If the sponsor leaves the organization, the lifecycle workflow in Step 3 handles the transfer.
You can assign co-sponsors for redundancy. At least one co-sponsor is recommended for any agent classified as business-critical.
Create a Blueprint
Navigate to M365 admin center > Agents > Blueprints > + New blueprint. For each blueprint:
- Name the blueprint descriptively (e.g., "HR Onboarding Agent — OBO")
- Select the authentication model (OBO for interactive agents, Client Credentials for autonomous)
- Assign the Conditional Access policy — OBO agents inherit the user's policies automatically; autonomous agents need their own assignment
- Designate a primary sponsor and at least one co-sponsor
- Define the permission boundary: which APIs and data sources the blueprint can access
Key decision: OBO agents inherit the user's Conditional Access policies automatically. Autonomous (client credentials) agents need their own Conditional Access assignment. If you are starting with Agent 365 today, begin with OBO agents only, since autonomous agent pricing is not yet defined.
Verify
Open Agents > Blueprints and confirm your new blueprint appears with the correct authentication model, sponsor, and Conditional Access policy. Activate the blueprint for a test security group, then have a member of that group launch the agent and confirm it authenticates correctly.
Step 3: Configure Lifecycle Workflows
This step requires an Entra ID Governance license (included in Entra Suite or M365 E7). If you do not have it, skip to the manual alternative below. You can still use Agent 365, but sponsor transitions will need manual handling.
Navigate to Lifecycle Workflows
Open the Entra admin center and go to Identity governance > Lifecycle workflows > Create a workflow.
Three Workflows to Configure
- Sponsor departure (leaver): When an agent's primary sponsor leaves the organization, automatically transfer sponsorship to the designated co-sponsor. If no co-sponsor exists, flag the agent as orphaned and notify the security team.
- Sponsor role change (mover): When a sponsor moves to a different department or role, verify the agent's permissions still align with the new organizational context. Trigger a review if the sponsor's new role does not include the required access.
- Co-sponsor notification: When a primary sponsor's status changes, automatically notify all co-sponsors so they can review agent configurations.
Manual Alternative (No Governance License)
If you do not have an Entra ID Governance license, set a calendar reminder to review agent sponsorship quarterly. Maintain a shared spreadsheet mapping each agent blueprint to its primary sponsor and backup contact. When HR notifies you of a departure, manually reassign sponsorship in Agents > Blueprints > [Blueprint name] > Sponsor.
Verify
After configuring a lifecycle workflow, test it by simulating a sponsor departure in a non-production Entra environment. Verify that the co-sponsor receives a notification and that the agent's blueprint reflects the updated sponsorship. If no test environment is available, confirm the workflow appears as Active in Identity governance > Lifecycle workflows.
Step 4: Enable Shadow AI Discovery
Your registry only shows agents you know about. Shadow AI discovery finds the ones you do not. Shadow AI refers to any AI tool or agent that employees use without IT approval — the AI equivalent of shadow IT. It includes locally installed CLI tools, browser extensions calling LLM APIs, and custom scripts hitting external model endpoints.
How It Works
Navigate to M365 admin center > Agent 365 > Shadow AI. Discovery uses two mechanisms working together:
- Microsoft Defender: Detects network-level agent traffic, API calls to external LLM providers, and unauthorized tool invocations.
- Microsoft Intune: Identifies locally installed agent software on managed Windows devices. This includes CLI-based tools like GitHub Copilot CLI, Claude Code, and other agents running outside the browser.
What Gets Discovered
Shadow AI discovery can surface agents from any vendor: OpenAI-based tools, Anthropic clients, open-source frameworks, and custom-built agents calling external APIs. The discovery engine does not distinguish by vendor. It catches anything making LLM API calls or running recognized agent binaries.
Enforcement Options
Once a shadow agent is discovered, you have three choices:
- Onboard it: Create a blueprint, assign a sponsor, bring it into the governed registry.
- Block it: Use Intune device policies to prevent the agent binary from running on managed endpoints.
- Monitor it: Leave it running but track its activity. Useful for evaluating agents before making a policy decision.
Coming soon: Context mapping and runtime blocking are scheduled for a June 2026 preview. This will add the ability to see what data shadow agents are accessing in real time, not just that they exist.
Triage Guidance
When shadow agents are discovered, prioritize by risk:
- High risk (onboard or block immediately): Agents handling customer data, PII, or accessing internal APIs
- Medium risk (monitor, then decide): Developer productivity tools (GitHub Copilot, code assistants) on managed devices
- Low risk (monitor): Standalone tools with no network access to internal resources
Verify
Navigate to M365 admin center > Agent 365 > Shadow AI and confirm that discovery results are populating. You should see agent detections within 24 hours if Defender and Intune are active. If the page is empty after 48 hours, verify that Defender for Cloud Apps and Intune are correctly licensed and that Windows devices are enrolled.
Step 5: Govern MCP Servers
Model Context Protocol (MCP) is an open standard that lets AI agents connect to external tools through a common interface. Instead of each agent needing custom integration code for every tool, the tool runs a small MCP server, and the agent talks to it using a standardized protocol. MCP servers give agents access to databases, APIs, file systems, and SaaS platforms. Agent 365 provides centralized control over which MCP servers your agents can use.
Navigate to MCP Controls
Open M365 admin center > Agents and Tools. This page lists all MCP servers that agents in your tenant have requested access to.
Allow/Block at the Server Level
For each MCP server, you can:
- Allow: Agents can connect to this server and use any of its tools.
- Block: No agents in the tenant can connect. Existing connections are severed.
- Scope: Apply allow/block rules per security group rather than tenant-wide.
Compensating Controls
Since per-tool governance is not available, layer these controls:
- Use Purview DLP policies to catch sensitive data in transit to allowed MCP servers
- Require agents using high-risk MCP servers to operate under OBO authentication so every call inherits the user's Conditional Access policies
- Audit MCP server connections weekly and review tool invocation logs in the Unified Audit Log
Example: Your organization uses an MCP server that connects agents to Salesforce. The server exposes 12 tools: read contacts, read opportunities, create leads, update pipeline stages, and so on. If you allow this server, agents can use all 12 tools. If the "create leads" tool does not meet your data classification requirements (it sends PII to Salesforce without encryption in transit), you must block the entire server — you cannot selectively disable just that tool. The workaround is to work with the MCP server vendor or your internal team to split the server into a read-only server (allow) and a write server (block or restrict).
The per-tool granularity gap is not unique to Agent 365. It reflects the current state of the MCP ecosystem: most MCP server implementations do not expose per-tool access control metadata, so governance platforms have limited options for fine-grained enforcement.
Verify
Open M365 admin center > Agents and Tools and confirm that MCP servers are listed with their current allow/block status. For any server in "Allowed" status, review the tool list and verify that every tool meets your data classification requirements. Check the Unified Audit Log for MCPServerConnection events to confirm logging is active.
Step 6: Connect Multi-Cloud Registry Sync
Registry sync is in public preview. It pulls agents from non-Microsoft platforms into your Agent 365 registry so you have a single view across clouds. Do not treat preview features as production-ready.
Setup
Navigate to M365 admin center > Agents > All Agents > Registry sync > Manage > + Connect a platform.
Supported Platforms
| Platform | What Syncs | Auth Required | Policy Depth |
|---|---|---|---|
| AWS Bedrock | Agents, models, guardrails configured in Bedrock | AWS IAM role with cross-account trust | Visibility + basic metadata |
| Google Vertex AI | Agents, endpoints, model deployments | Google Cloud service account with Vertex AI Viewer role | Visibility + basic metadata |
Reality check: "Policy enforcement is shallower for non-Microsoft ecosystems" means you get visibility into what agents exist on AWS and Google, but you cannot enforce Entra Conditional Access or Purview DLP on those agents the way you can for native Microsoft agents. Use registry sync for inventory and risk mapping, not as a governance enforcement boundary.
Verify
After connecting a platform, navigate to Agents > All Agents and filter by source. You should see agents from the connected platform within 30 minutes. Verify that the synced agent metadata (name, type, model) is accurate by cross-referencing with the source platform's console. If no agents appear, check the service account permissions and confirm the cross-account trust (for AWS) or Viewer role (for Google) is correctly configured.
Step 7: Monitoring and Compliance
With the registry populated and policies assigned, configure your monitoring stack. Agent 365 integrates with the Purview compliance suite and Defender for ongoing oversight.
Data Security Posture Management (DSPM) for AI
DSPM for AI extends Purview's data classification to agent interactions. It identifies when agents access, process, or transmit sensitive data and maps those interactions to your existing sensitivity labels (the classification tags — Confidential, Internal, Public — that Purview applies to documents and data). This is generally available.
Insider Risk Management (IRM) for Agents
IRM for Agents extends insider risk signals to include agent-mediated activities. If a user's agent starts accessing data outside their normal pattern, IRM flags it the same way it would flag a human user. This feature is in preview (expected GA in weeks from the May 2026 announcement).
Unified Audit Log
All agent activities flow into the M365 Unified Audit Log. This includes agent activations, MCP server connections, tool invocations, blueprint changes, and sponsor assignments. Use these logs for incident response, compliance reporting, and anomaly detection.
eDiscovery
Agent conversation content is now subject to eDiscovery holds and search. This is generally available as of the Build 2026 announcement. Any interaction between a user and a managed agent is discoverable.
Recommended Audit Cadence
- Weekly: Review shadow AI discoveries, MCP server connection requests, and orphaned agent alerts
- Monthly: Audit sponsor assignments, review blueprint permission scopes, check registry sync health for multi-cloud connections
- Quarterly: Full access review of all active agent blueprints, compare agent inventory against approved agent catalog, update DLP policies for new data types
Verify
Open the Unified Audit Log and search for RecordType: Agent365 events. Confirm that agent activations, blueprint changes, and MCP server connections are generating log entries. If DSPM for AI is enabled, navigate to Purview > DSPM for AI and verify that agent interaction data is flowing into the dashboard.
Pricing: The Hybrid Cost Model
Agent 365 pricing has two layers, and conflating them is the most common budgeting mistake organizations make.
Layer 1: Governance (Per-Seat)
The Agent 365 license covers the control plane: registry, identity blueprints, lifecycle management, shadow AI discovery, and compliance features. This is a per-user cost.
| License | Price | What It Includes |
|---|---|---|
| Agent 365 Standalone | $15/user/month | Full Agent 365 governance features |
| Microsoft 365 E7 | $99/user/month | E5 + Copilot + Entra Suite + Agent 365 |
| Components Purchased Separately | ~$117/user/month | Same components without bundle discount |
Layer 2: Execution (Consumption)
Running agents costs money on top of the governance license. These costs scale with usage and are the hardest to predict.
| Service | Unit | Cost |
|---|---|---|
| Copilot Studio Capacity | 25,000 credits/month | $200/month |
| Copilot Studio Pay-As-You-Go | Per credit via Azure | $0.01/credit |
| SharePoint Agent Queries | Per query (unlicensed users) | $0.12/query |
| Security Copilot SCU Overage | Per SCU (Security Compute Unit — Microsoft's billing unit for Security Copilot processing) | $6/SCU |
E5 and E7 tenants get a baseline of 400 SCUs per 1,000 users. Overages are billed at $6/SCU. Copilot Studio credits expire monthly and do not roll over.
Budget planning risk: Microsoft has not published expected costs per agent, TCO reference architectures, or consumption guidance for common deployment patterns. Plan conservatively and set Azure cost alerts on all agent-related resource groups.
Known Limitations
Agent 365 is newly generally available (GA at Build 2026, May 2026). The feature set is still evolving. These are the gaps that matter most for deployment planning.
Frequently Asked Questions
A centralized governance layer for AI agents in Microsoft 365 — it watches, manages, and secures agents but does not build or run them. If you currently manage Entra identities and Conditional Access for human users, Agent 365 extends that same governance model to non-human agents. The quickest way to evaluate it: assign a single Agent 365 license, open the registry, and see which agents are already active in your tenant.
Two layers. The governance license ($15/user/month standalone, or included in M365 E7) covers the control plane. Execution costs stack on top: Copilot Studio credits, SharePoint agent queries, and Security Copilot compute units. A common gotcha is budgeting only for the governance license and being surprised by consumption charges. See the Pricing section in this guide for the full breakdown and a worked E7 bundle comparison.
Partially. Shadow AI discovery catches non-Microsoft agents on Windows devices. Registry sync (public preview) pulls agents from AWS Bedrock and Google Vertex AI into your inventory. The practical limit: you get visibility into these agents but cannot enforce Entra Conditional Access or Purview DLP on non-Microsoft platforms. For multi-cloud governance, pair Agent 365 with each platform's native controls — for example, AWS IAM guardrails for Bedrock agents.
Not yet — and this is the most impactful gap for most deployments. You can allow or block entire MCP servers, but you cannot disable individual tools within an allowed server. The practical workaround: ask your MCP server vendor or internal team to split servers into separate read and write instances, then allow only the read instance. Layer Purview DLP on top to catch sensitive data in transit.
Entra ID Governance — a separate add-on license included in Entra Suite and M365 E7. Without it, everything else in Agent 365 still works; you just lose the automated sponsor-transfer and orphan-flagging workflows. Many organizations start without it and add the license once their agent inventory exceeds 20-30 managed blueprints, which is the point where manual sponsor tracking becomes unsustainable.