Microsoft Agent 365 Security

Last Updated on October 1, 2026 by Arnav Sharma

AI agents are entering production faster than most security teams can inventory them. An agent that triages support tickets, another that reorganises an inbox, a third that queries a data warehouse overnight: each one holds credentials, touches sensitive data, and acts without a human watching every step. Microsoft Agent 365 Security is Microsoft’s answer to that problem. It positions Agent 365 as a unified control plane to observe, govern, and secure every agent across a Microsoft 365 tenant, extending the identity, data, and threat controls you already run for people to the non-human workforce now operating alongside them.

This is not another product to bolt on. For a security architect, the value is that Agent 365 reuses Microsoft Entra, Microsoft Purview, and Microsoft Defender rather than inventing a parallel governance stack. The hard part is knowing which controls map to which risks, what is generally available versus still in preview, and how to roll it out without leaving gaps. This guide works through that decision layer, not just the feature list.

Why AI agents break traditional security models

Traditional identity and access management assumes a human on one end of every session. A person authenticates, a policy evaluates their risk, and an audit log records what they did. AI agents violate that assumption in several ways at once, and each one widens the attack surface.

The first problem is sprawl. Business users and developers can spin up agents in Copilot Studio, in third-party SaaS tools, and on external platforms with little friction. Microsoft describes this directly as agent sprawl, and the governance challenge is blunt: you cannot govern what you cannot see, and you cannot secure what you do not understand. Every agent you fail to discover is an unmanaged identity with standing access.

The second problem is over-privileged access. Agents accumulate permissions to data, apps, APIs, and tools, and those permissions rarely get pruned. An agent provisioned for a single workflow can end up holding broad access to resources it no longer needs. In identity terms, this is privilege creep applied to a workforce that never sleeps and never forgets a token.

The third problem is a new class of runtime threat. Prompt injection, tool misuse, and data leakage now extend across agent interactions rather than staying contained in a single chat window. An agent manipulated into abusing an authorised tool can cause damage using entirely legitimate permissions, which is precisely the kind of behaviour traditional signature-based defences miss.

The fourth problem is accountability. When an agent takes an action, who owns the consequence? Ownerless or risky agents accumulate quietly, and without a sponsor model, there is nobody responsible for reviewing an agent’s access or retiring it. For any organisation with compliance obligations, an action with no accountable owner is an audit finding waiting to happen.

What Microsoft Agent 365 is: the control plane for AI agents

Microsoft Agent 365 is the control plane for AI agents. It does not build agents and it does not run them. Its job is narrower and more useful: to make sure every agent in your organization has an identity, a sponsor, an access policy, and an audit trail. Think of it as the management surface that sits above the agents themselves, giving IT and security teams a single place to observe, govern, and secure them.

Agent 365 is generally available for the commercial segment as of May 2026, licensed on a per user basis. It functions as the unified control plane that brings agents built with Microsoft AI platforms, agents from ecosystem partners, and agents you register yourself into one managed view.

Delegated versus autonomous agents

The single most important distinction for a security architect is how an agent authenticates and acts, because it changes every control decision that follows. Agent 365 covers two broad patterns.

Delegated agents act on behalf of a user with that user’s access. An agent that helps an employee organise their inbox inherits and operates within the boundaries of that person’s permissions. The blast radius is bounded by the sponsoring user’s access.

Autonomous agents operate with their own credentials and permissions. An agent that autonomously triages support tickets participates in workflows using its own identity and scope of work, independent of any single user session. This is the higher-risk pattern, because the agent’s access is not tied to a human’s session and can persist and act continuously.

Getting this classification right early matters. A delegated agent can often be governed through the sponsoring user’s existing conditional access and data policies. An autonomous agent needs its own identity, its own least-privilege scope, and its own lifecycle review, because there is no human session to anchor the controls to.

The agent registry and visibility

Visibility is the precondition for everything else. The Agent 365 registry, surfaced through the Microsoft 365 admin center, gives administrators a complete view of all agents in the organization: agents with an Entra Agent ID, agents you register yourself, and shadow agents discovered in the environment. This is the single inventory that closes the discovery gap.

The registry does more than list agents. It provides a unified view of agent adoption, activity, and agent health, and it surfaces governance signals such as agents at risk, agents without owners, and agents with exceptions. This is the foundation of agent management: from a single surface you can manage agent lifecycle, review agent access to resources each one touches, and drive agent governance decisions across the whole estate, from initial agent deployment through retirement. For a security team, that turns a blind spot into a worklist. You can see which agents carry aggregated high-severity risks across Microsoft Entra, Microsoft Defender, and Microsoft Purview, and act on them before they cause an incident.

How Agent 365 secures agents across three planes

Agent 365 extends the existing infrastructure you use for managing people to agents. Rather than a separate security product, it applies purpose-built agent controls through three components you likely already operate: Microsoft Entra for identity, Microsoft Purview for data, and Microsoft Defender for threats. The Agent 365 overview in the Microsoft 365 admin center is where this comes together, giving you the vantage point to secure AI agents at scale, establish guardrails for agents across the organization, and confirm controls apply to agents in your environment consistently. Understanding how each plane contributes is the core of securing AI agents at scale.

Identity in Microsoft Entra

Identity is the foundation. Microsoft Entra gives every agent a distinct identity, the Entra Agent ID, so that agent activity can be attributed, policed, and audited the same way user activity is. This is what makes access control for agents tractable: an agent with an identity is an object you can apply policy to.

Microsoft Entra enforces consistent, risk-based access controls for both users and the agents acting on their behalf. Practically, this means extending conditional access and identity protection policies from users to agents, so an agent operating from an unexpected context can be challenged or blocked. It also means enforcing least-privilege access, so an agent only reaches the resources it genuinely needs. Security teams define governance requirements as policy templates, such as access packages in Entra, and IT applies those templates during onboarding so guardrails are in place from the first day an agent runs. Because agent IDs are managed the same way user identities are, a single agent policy can travel with an agent from deployment through retirement. That template-first approach is how you govern agents across the organisation consistently rather than one at a time.

Data governance with Microsoft Purview

Agents create, access, and share data across systems, which increases the risk of oversharing and sensitive data exposure. Microsoft Purview controls what data agents can access and how they use it. Two capabilities matter most here.

Data security posture management gives deep interaction visibility for agents and identifies AI-related data exposure risks, so you can see where an agent’s behaviour is creating exposure before it becomes a leak. Sensitivity labels are inherited and honoured by agents, which means the same protection you apply to human interactions carries across to agent interactions without a separate policy set. Purview also extends data loss prevention to agent activity and logs what data agents access, create, or share, producing the audit trail that supports compliance obligations across the agent lifecycle.

Threat protection with Microsoft Defender

Microsoft Defender adds continuous threat detection and real-time protection, blocking unsafe behaviours and malicious activity during agent runtime. This is the layer that addresses the runtime threats traditional tooling misses: an agent being manipulated through prompt injection, or one being steered into misusing a tool it is authorised to use. Defender monitors agent behavior for these patterns and can intervene while the agent is running, not only after the fact in a log review.

Together, these three planes ensure agents only access authorised resources, prevent data leakage, and defend against evolving threats. The design intent is that no single plane carries the whole load: Entra constrains who and what an agent can be, Purview constrains the data it touches, and Defender watches how it behaves. In this way Agent 365 delivers end-to-end protection for every agent, and it empowers organizations to move from agent experimentation to enterprise-scale operations without loosening their security posture.

Agent 365 risk-to-control mapping

The most useful thing a security architect can do with Agent 365 is map each agentic risk to the specific control that addresses it. The table below does that, drawing on Microsoft’s own description of the agent risks and the corresponding capabilities.

Agentic risk	What goes wrong	Primary control	Where it lives
Agent sprawl and shadow agents	Unmanaged agents with standing access nobody tracks	Central registry and discovery of every agent	Microsoft 365 admin center
Over-privileged agents	Excessive access to data, apps, APIs, and tools	Least-privilege access and access packages	Microsoft Entra
Weak or missing identity	Actions cannot be attributed or policed	Distinct agent identity (Entra Agent ID)	Microsoft Entra
Risky sign-in context	Agent acts from an untrusted condition	Conditional access extended from users to agents	Microsoft Entra
Data oversharing and leakage	Sensitive data exposed through agent activity	DLP, sensitivity labels, posture management	Microsoft Purview
Prompt injection and tool misuse	Agent manipulated into harmful runtime behaviour	Continuous threat detection and runtime protection	Microsoft Defender
Ownerless agents	No accountability, no lifecycle review	Sponsor assignment and lifecycle governance	Microsoft 365 admin center
Non-compliant agent behaviour	Audit and retention gaps	Auditing, retention, compliance controls	Microsoft Purview

Reading the table as an architect, the pattern is clear: identity problems resolve in Entra, data problems in Purview, behavioural problems in Defender, and accountability problems in the admin center registry. If a proposed rollout leaves any row unaddressed, that is a gap worth flagging before you sign off.

What is generally available versus preview

Honest capability maturity is where vendor documentation tends to go quiet, and it is exactly what a security architect needs before committing to a control. Agent 365 reached general availability for the commercial segment in May 2026, but not every capability in the platform is production-ready at the same level. Some sit in public preview, which changes how much you should rely on them for a control you are certifying.

The table below summarises the maturity picture based on Microsoft’s launch communications. Treat preview capabilities as promising but not yet suitable as the sole control for a high-severity risk.

Capability	Status at launch	Implication for security teams
Agent registry and visibility	Generally available	Rely on it as your primary inventory
Entra Agent ID and conditional access	Generally available	Use as the identity control baseline
Purview data controls (DLP, labels)	Generally available	Extend existing data policy to agents
Coverage for autonomous agents with own credentials	Expanding via preview	Validate before trusting for high-risk agents
Registry sync with AWS Bedrock and Google Cloud	Public preview	Gives visibility, not full policy enforcement
Full Defender-based runtime threat protection	Maturing at launch	Do not treat as the sole runtime control yet

The practical takeaway: multi-cloud registry sync will discover and inventory agents running on AWS Bedrock and Google Cloud, but you cannot enforce Entra conditional access or Purview DLP on those non-Microsoft platforms today. You get visibility into those agents, which is genuinely valuable, but not the same enforcement you get inside Microsoft 365. Plan your compensating controls accordingly.

Licensing and where it fits: Microsoft 365 E7

Agent 365 is available as a standalone per-user license and is also bundled into Microsoft 365 E7, Microsoft’s top-tier enterprise suite positioned for organisations operationalising AI at scale. E7 combines the productivity and security of the prior top tier with Microsoft 365 Copilot and the Agent 365 control plane for AI agents, plus advanced Entra, Defender, and Purview capabilities.

For budgeting, one nuance matters. The governance license covers the control plane, but execution costs stack on top: Copilot Studio consumption, agent query volume, and Security Copilot compute are separate. Agent 365 provides the governance layer, while Microsoft Copilot and Copilot-built agents generate the execution activity underneath it. Teams that build custom agents with the Agent 365 SDK, or that rely on discovery of non-Microsoft agents surfaced through Microsoft Edge on managed devices, should account for those flows in the same model. A common planning mistake is budgeting only for the governance license and being surprised by consumption charges once agents move from pilot to production. Model both layers before you commit, and use Microsoft’s published licensing guidance to validate the numbers for your tenant.

The strategic question is not really about the license. It is whether your organisation is ready to move from ad hoc agent experimentation to a human-led, agent-operated model with governance built in. Agent 365 is the mechanism that makes that shift defensible, because it treats each agent as a managed identity subject to the same discipline you already apply to privileged human accounts.