Organisations are about to have more AI agents than employees, and most of them have no idea how many they already have. Microsoft Agent 365 is the answer to that problem: a control plane that gives every agent its own identity and brings the fleet under the same governance that already covers people. It is a genuinely useful piece of plumbing, and it also quietly changes your attack surface, because an agent with an identity and permissions is a new kind of privileged actor. This is what it is, and how to secure it.
First, the shape of it. Agent 365 was announced at Ignite in late 2025 and became generally available in 2026. It is not a standalone security product. It is a governance and observability layer built on Microsoft Entra Agent ID that extends Entra, Purview and Defender to cover AI agents, which traditional identity and access frameworks never accounted for. It gives IT one place to manage users, apps and agents together. Three things sit at its core: a registry (a single inventory of every agent, so you can see them before they sprawl), access control (every agent gets a unique identity and only the access it needs), and governance and observability across Purview, Defender and Sentinel.
The agent identity model
This is the part that matters most, because almost every agent security problem is an identity problem. Agent 365 is built on Entra Agent ID, and the identity is not a single object. It is a chain: a blueprint defines the kind of agent, a blueprint principal represents it, an agent identity is the directory identity itself, and an agent user is the agent as a first-class actor that can have a mailbox and a Teams presence like a person. Every registered agent gets an Entra Agent ID with owners, sign-in logs and a risk score, and that identity is what ties Defender, Entra and the admin centre together.
Two consequences of this model drive the whole security approach.
An agent runs with its own permissions, usually broader than the person who triggered it. And one blueprint can be instanced many times, so you can have many running copies of the same agent. The requirement that follows: every instance that runs a task needs its own identity and the least privilege for that task, kept on a separate footing from human roles. Share one identity across instances and you lose both attribution and the ability to contain one without stopping all.
Because the agent acts under its own, more privileged identity, a manipulated agent does things the user never could. Plant a hostile instruction in a document the agent later reads, and it carries it out with its own legitimate access. The defence is not a cleverer model, it is a narrow identity: an agent that can barely reach anything is a confused deputy that can barely do harm.
Securing and governing the fleet
Agent 365 does not invent new security tools; it points the ones you have at agents. The baseline is a small set of requirements, and the honest framing is that the platform gives you the levers, but an agent with a broad identity and open tools is still dangerous until you pull them.
Register every agent so there are no shadow agents, give each a unique Entra Agent ID with least privilege, and apply Conditional Access to agent identities as you would any privileged principal. This is the control that does the most work.
Scope each agent to only the tools it needs, with the default being none. Keep content and prompt-injection controls on the inputs an agent reads, so untrusted text cannot widen its scope or trigger an unapproved action. Gate any write or high-impact action behind human approval.
Microsoft Purview classifies and prevents sensitive data leaving through an agent, with data minimisation so an agent keeps only what its task needs. The platform commits that your data is not used to train foundation models without instruction, but the default retention for abuse monitoring is one to change where the data is sensitive.
Rate limits, spend caps and circuit breakers. A prompt-injected or runaway loop can burn a large sum quickly, so denial of wallet is a real threat, not a footnote.
Seeing it in the SIEM, and this part just changed
An agent you cannot see and cannot stop is the real worst case, so getting agent telemetry into Microsoft Sentinel is the control that makes the rest enforceable. This is also the part that moved recently, so it is worth being precise about the current state rather than repeating what was true a few months ago.
Until recently there was no out-of-the-box path from Agent 365 into Sentinel, and teams built custom routes. That has changed: native connectors now exist, in public preview. The decision is therefore no longer how to build a route, it is whether your organisation permits preview connectors in production.
If your organisation allows preview in production, the native route is the simplest and richest: install the Agent 365 connector from the Sentinel Content Hub to stream activity into the data lake (UnifiedAgentObservability), add the Agent Identities connector for the inventory and blueprint tables, the Copilot connector for CopilotActivity, and send the Entra agent risk logs (RiskyAgents, AgentRiskEvents) through diagnostic settings. Defender XDR then detects on agents through its Agent 365 integration.
If it holds to non-preview only, use an interim route until the connectors reach general availability: Foundry diagnostic settings and the OpenTelemetry exporter into the Sentinel-enabled workspace, and a codeless REST poller or a scheduled function writing the mandatory Agent 365 telemetry to the Logs Ingestion API through a Data Collection Rule. Record the choice, either the preview exception or the interim route, as an architecture decision with a review date tied to the connectors going GA.
The kill switch
The backstop for everything above: a control that can stop a live agent. Implement it as an approved Sentinel playbook or a documented manual procedure that, on authorisation, stops the agent's runtime and disables its Entra agent identity, logs the containment, and requires a separate approval to restore. The design points that matter are that it acts on the agent's own unique identity, which is exactly why the one-identity-per-instance rule is load-bearing, that it is reversible only through an approval gate, and that it is tested, not just written down. An untested kill switch is an assumption, not a control.
The shape of it
Agent 365 is a sensible and overdue answer to agent sprawl: give every agent an identity, put the fleet in a registry, and govern it with the Entra, Purview and Defender controls you already run. The security of it comes down to the same handful of things every time. Keep each agent's identity unique and narrow. Grant it only the tools it needs. Stop untrusted input from changing what it can do. Get its telemetry into Sentinel, which just became much easier now the native connectors exist in preview. And have a tested way to switch it off. Do that, and an agent with its own identity is an asset you can govern. Skip it, and you have given a privileged, non-human actor to anyone who can write the text it reads.
Download the design patternA generic, reusable AI Agent 365 security baseline: identity, guardrails, telemetry to Sentinel and the kill switch. PDF. Download PDF ↓If you are rolling out agents on Agent 365 or Foundry and want them designed to be contained, identities scoped, telemetry wired and a kill switch in place, before they go live, that is the work I do through Cyber Spartans.