Agent 365 - what Purview practitioners need to know

If your organisation uses Copilot Studio or Azure AI Foundry, people can already build AI agents that connect to your Microsoft 365 data. Agent 365 does not replace those tools. It is the governance and management layer that sits on top of them.

Think of it as the admin centre for agents. It gives you three things you do not have today:

Entra Agent ID - a dedicated identity type for agents. Agent identities are built on the existing service principal infrastructure but with an agent-specific subtype and behaviours. Each agent gets its own first-class identity rather than sharing a generic app registration. That means you can apply conditional access, audit its activity, and manage its lifecycle the same way you manage user identities.

Agent Registry - a single inventory of every agent in your tenant, regardless of where it was built. Copilot Studio agents, Azure AI Foundry agents, third-party agents - they all show up in one place. You can see what each agent connects to, who owns it, and whether it has triggered any risk alerts. Critically, it also surfaces shadow agents that users have built without IT involvement.

Security and compliance integration - agents become first-class entities across Entra, Defender, and Purview. Identity governance, threat detection, DLP, sensitivity labels, audit - all extended to cover agent interactions.

Current status: Agent 365 is only available through the Frontier preview programme. You need at least one Microsoft 365 Copilot licence to enable it. There is no public GA date yet.

Entra is where agent governance starts. Without proper identity, you cannot apply policies, audit activity, or manage lifecycle.

Agent permissions. Every agent requests permissions to access your data - and these permissions matter. Agents can have application permissions (act without a user signed in, with org-wide access to things like all groups, all user profiles, and all teams) or delegated permissions (act on behalf of a signed-in user, accessing their mailbox, chats, meetings, and channels). You can review exactly what each agent has access to in the Permissions tab on the agent details page in the M365 admin centre. During publishing or deployment, admins must review and grant consent for these permissions. This is your chance to enforce least-privilege - do not rubber-stamp consent without reading what the agent is asking for.

Agent sponsors and ownership. Every agent needs a human or group sponsor accountable for its lifecycle - sponsors are required when creating agent identities. They can enable or disable agents but cannot modify application settings. If a sponsor leaves and no succession plan is in place, the agent becomes ownerless - a governance risk you need to watch for. Lifecycle Workflows sponsor tasks (preview) can help by notifying managers and co-sponsors when a sponsor moves or leaves.

Conditional Access for agents. You can create CA policies that target agent identities specifically. These are separate from your user CA policies - agents need their own. Currently, the only condition available is agent risk level (from ID Protection) and the only grant control is Block. This is a lightweight enforcement mechanism designed to block risky agents, not a full policy suite like user CA.

Entra ID Protection. Behavioural anomaly detection for agents - it flags when an agent accesses unfamiliar resources, shows unusual sign-in patterns, or has a high number of authentication attempts. Same concept as user risk detection, applied to agents.

Global Secure Access (preview). For agents built in Copilot Studio, you can apply network-level controls - web content filtering, threat intelligence filtering, and network file filtering on HTTP Node, custom connector, and MCP Server Connector traffic. This is your network perimeter for agents.

Agent lifecycle governance. Entitlement Management lets you create access packages for agents with built-in expiry dates and sponsor approval. Lifecycle Workflows sponsor tasks (preview) can automatically notify managers and co-sponsors when a sponsor moves or leaves, helping prevent orphaned agent access.

Defender XDR gives you threat detection and investigation for agent activity.

CloudAppEvents table. All agent activity flows into the CloudAppEvents table in Defender XDR with new action types specifically for agents: InvokeAgent, InferenceCall, ExecuteToolBySDK, ExecuteToolByGateway, and ExecuteToolByMCPServer. These give you granular visibility into what agents are doing - invoking tools, making inference calls, using MCP servers, and interacting with other agents.

Out-of-the-box detections. Microsoft provides pre-built detection rules that flag known threats and risky agent behaviours automatically. Alerts trigger without manual configuration.

KQL hunting. You can write advanced hunting queries to proactively search for suspicious agent activity. A basic starting query filters CloudAppEvents for agent action types. From there, you can build custom detection rules for your specific agent workflows.

Real-time runtime protection (preview). For Copilot Studio agents, Defender for Cloud Apps can inspect tool invocations before the agent executes them. If it detects a suspicious prompt or malicious tool call, the action is blocked before it runs, the user is notified, and an alert is created. This requires onboarding with your Power Platform administrator.

Prerequisites to get this working: Unified audit logging must be enabled in Purview. The Microsoft 365 connector in Defender for Cloud Apps must be configured and flowing data. Your security team needs the right RBAC roles in the Defender portal. Without these three things in place, agent activity is invisible to Defender.

Purview controls extend to agent interactions the same way they work for users, with some important differences.

DSPM AI observability is your monitoring dashboard. The new DSPM preview includes an AI Observability page showing every agent with activity in the last 30 days, prioritised by risk level. You can drill into each agent to see its identity, owner, and risky activities. Important: only the new DSPM preview supports this. Classic DSPM does not.

DLP policies work on agent interactions across Teams, SharePoint, OneDrive, and email. Microsoft docs state that agent instances can be added to policies the same way you add a user or security group, but per-agent scoping is not yet visible in the DLP policy UI. For now, ensure your DLP policies cover all locations where agents operate.

Sensitivity labels protect content from agent access. Agents do not have their own identity for encryption checks - they use the invoking user's permissions. If the user has VIEW but not EXTRACT on an encrypted file, the agent cannot return the content even though the user can open the file themselves. Permission levels like Reviewer and Do Not Forward do not include EXTRACT. Co-Author and Co-Owner do. Broad scopes like "all users in your organisation" work fine as long as the assigned permission level includes EXTRACT. Also important: agent output does not automatically inherit sensitivity labels except in Word and PowerPoint, where the highest-priority label from referenced files is applied.

Insider Risk Management has two relevant templates. The Risky AI usage template detects users sending sensitive data to AI tools. The Risky Agents template (preview) specifically targets agent behaviour - agents generating sensitive responses, accessing sensitive SharePoint files, accessing risky websites, and sharing files externally. The Risky Agents template is applied by default for all organisations.

Audit logging captures all agent interaction types - agent-to-human, human-to-agent, agent-to-tools, and agent-to-agent. Every prompt, response, tool execution, and data access is recorded.

eDiscovery searches agent interactions in user mailboxes. Data Lifecycle Management applies retention policies to agent data. Communication Compliance scans agent interactions for policy violations. Note: encryption without sensitivity labels is not supported for Agent 365 - you must use labels.

Encryption permission levels matter more than you think. Agents check the invoking user's permissions, not their own. If your encrypted labels use a permission level that does not include EXTRACT - like Reviewer or Do Not Forward - agents cannot return the content, even though the user can view the file. Co-Author and Co-Owner include EXTRACT. Check every encrypted label.

New content from agents does not inherit labels (mostly). When an agent creates a document based on labelled source material, the new document is not automatically labelled or encrypted - except in Word and PowerPoint, where the highest-priority label from referenced files is inherited. In Copilot Chat, the label is displayed in the response but not formally applied. An agent could read a Restricted document and create an unlabelled summary that anyone can access.

DLP blocks are invisible to agents. When DLP blocks an agent action, the agent itself is unaware it was blocked - no retry logic and no notification to the agent owner. In some scenarios users may see a message, but the agent owner must proactively monitor DLP alerts to catch disrupted workflows.

Conditional Access for agents is separate from user CA. Your existing user policies do not automatically cover agents. You need dedicated CA policies targeting agent identities.

Defender needs the M365 connector enabled. CloudAppEvents data for agents only flows if the Microsoft 365 connector is configured in Defender for Cloud Apps. This is not on by default.

Encryption without sensitivity labels is not supported. If you use standalone encryption (without labels), it does not work with Agent 365. You must apply encryption through sensitivity labels.

Agent permissions can be overly broad. When you publish or deploy an agent, you are asked to grant admin consent for its permissions. Application permissions like Group.Read.All or User.Read.All give org-wide access without a user being signed in. Delegated permissions like Mail.ReadWrite let the agent read and modify emails on behalf of users. Do not auto-approve - review each permission and apply least-privilege.

Shadow agents are already in your tenant. If users have Copilot Studio access, they may have built agents without IT awareness. The Agent Registry in the M365 admin centre already shows these - but only if someone actually reviews it. Use the Defender for Cloud Apps AI agent inventory for deeper discovery.

Information Barriers do not apply to embedded files. If an agent uses uploaded files as a knowledge source, those files are stored in SharePoint Embedded containers. Information Barriers are not supported on these files - any user who can access the agent can see responses based on the embedded content.

You do not need to wait for Agent 365 to go GA. Most of the preparation is work you should already be doing.

Identity (Entra)

1. Check the Agent Registry for your current agent footprint. Find out what agents exist, who built them, and whether any are shadow agents.

2. Assign human sponsors to all agents. Check for ownerless agents.

3. Review agent permissions. In the admin centre, check the Permissions tab for each agent. Look for application permissions with org-wide scope and delegated permissions that access mailboxes or chats. Revoke anything that is not needed.

4. Create Conditional Access policies targeting agent identities. Do not assume your user CA policies cover agents.

Security (Defender)

5. Enable unified audit logging in Purview if not already on.

6. Configure the Microsoft 365 connector in Defender for Cloud Apps.

7. Build KQL hunting queries for CloudAppEvents agent action types. Start with a basic query filtering for InvokeAgent, InferenceCall, ExecuteToolBySDK, ExecuteToolByGateway, and ExecuteToolByMCPServer.

Data (Purview)

8. Get your sensitivity labels right. Agents use the invoking user's permissions, so ensure your encrypted labels assign permission levels that include EXTRACT (Co-Author or Co-Owner, not Reviewer). Use the Label Taxonomy Builder to plan your structure.

9. Review your DLP policies. Make sure they cover all agent interaction locations. Use the DLP Policy Simulator to test coverage.

10. Enable the risky AI usage template in Insider Risk Management.

11. Move to the new DSPM preview. It is the only version with Agent 365 observability.

12. Enable sensitivity labels for SharePoint and OneDrive. Without this, agents can only access encrypted files via Office apps on Windows.

The bottom line: Agent 365 is not a new product to learn from scratch. It is the governance layer for the controls you already have across Entra, Defender, and Purview - applied to agents instead of just users.