AI Agent Security and Governance with Microsoft Agent 365

An agent combines a language model with access to data and the ability to act. That combination introduces risks that traditional application security does not fully cover. The OWASP Top 10 for LLM Applications is a good reference list.

Agents differ from chat assistants because they can act. A chat assistant that misreads a document gives a wrong answer; an agent that misreads one may send an email, update a record or share a file. That is why the controls focus on what an agent is allowed to do, not only on what it can read. Agents that browse the web or read inbound email deserve the most care, because they process content written by outsiders, which is exactly where prompt injection hides.

• Microsoft Agent 365 provides the registry and control plane: discovering agents, assigning owners and managing their lifecycle. It became generally available on 1 May 2026.
• Microsoft Entra Agent ID gives each agent its own identity, so access reviews, conditional access and sign-in logs work for agents as they do for people.
• Microsoft Purview applies sensitivity labels, data loss prevention and data security posture management for AI, showing which sensitive data agents and assistants touch.
• Microsoft Defender monitors for threats against AI workloads and feeds alerts to your SOC.

Licensing and feature availability change often in this area, so we confirm the current position for your tenant before designing. Agents built on non-Microsoft platforms still need the same four controls; where the Microsoft tools cannot see them, we cover the gap with process and the existing SOC monitoring.

Most organisations already own part of this stack through Microsoft 365 E5 or security add-ons, but the features are rarely configured for agents. A practical starting point is to switch on the AI-related reports in Purview to see which sensitive data assistants and agents are touching, then use that evidence to prioritise permission clean-up. Entra access reviews can then be extended to agent identities so owners confirm, at set intervals, that each agent still needs its access. Where an agent uses a connector to a non-Microsoft system, such as an ERP or CRM, the connector account is the real access boundary, so it should be scoped and monitored like any privileged service account.

1. Every agent has a named business owner and a written purpose.
2. Data sources and their classification are recorded; agents touching personal data have a privacy review under PDPL, or DIFC or ADGM rules where they apply.
3. Actions are split into read, draft-for-approval and act-alone, and act-alone actions are limited and logged.
4. Each agent has its own identity, not a shared account.
5. Users are told when they are interacting with an agent.
6. Logs of prompts, actions and outcomes are kept for an agreed period.
7. Agents are reviewed at set intervals and retired, with access removed, when no longer needed.

See also why agentic AI has become an identity problem.

Keep the process proportionate. A personal agent that summarises a user's own meetings does not need the same review as an agent that answers customers or updates finance records. A simple tiering model works well:

Record the tier in the agent register so reviews happen at the right frequency: yearly for personal agents, perhaps every six months for team agents and quarterly for anything that serves customers or changes business data. When an owner leaves the organisation, their agents should be reassigned or retired as part of the normal leaver process, in the same way as their mailbox and files. This one step closes the most common gap we see, which is agents that keep running with broad access long after anyone remembers why they were built.