Microsoft Agent 365 raises the bar on AI agent identity governance

TL;DR: Microsoft Agent 365 adds identity primitives such as agent IDs, lifecycle rules, policy templates, risk-based access and auditability, but the control plane remains bounded by the Microsoft ecosystem while enterprise agents run across Azure, AWS, GCP, SaaS and CI/CD systems. The real security problem is cross-environment governance, not isolated agent administration.

At a glance

What this is: Microsoft Agent 365 formalises AI agents as non-human identities with lifecycle, policy and audit controls inside Microsoft environments.

Why it matters: It matters because IAM teams now need a governance model for autonomous agents that spans clouds, SaaS and build systems, not just a single vendor control plane.

👉 Read Microsoft's analysis of Agent 365 and AI agent identity governance

Context

AI agents create a governance gap because they behave like identities, but they are often deployed faster than existing IAM, secrets and audit models can track them. Once agents can call APIs, use tokens and move data across environments, they inherit the same security obligations as other non-human identities. That makes cross-environment discovery the first control problem, not the last.

Microsoft's Agent 365 pushes that conversation forward by treating agents as managed identities rather than loose automations. The limitation is structural: most enterprise agents already span multiple clouds, SaaS applications and CI/CD systems, so a single-provider control plane can only cover part of the risk surface.

For practitioners, this is a familiar pattern. Centralised controls inside one ecosystem help, but they rarely eliminate sprawl when workloads, secrets and agents are distributed across the enterprise.

Key questions

Q: How should security teams govern AI agents across multiple clouds?

A: Start with a central inventory of every agent, its owner, its credentials and the systems it can reach. Then apply least privilege, continuous monitoring and revocation paths across each cloud and SaaS platform. If the policy cannot follow the agent across environments, the governance model is incomplete.

Q: Why do AI agents create a bigger IAM problem than service accounts?

A: AI agents can change behaviour, call new tools and expand their access patterns faster than static service accounts usually do. That means their risk is not only authentication, but drift, hidden entitlements and cross-environment movement. Teams need identity governance that follows runtime behaviour, not just issued credentials.

Q: What is the difference between agent identity governance and secrets management?

A: Secrets management protects the tokens, keys and certificates an agent uses. Agent identity governance also covers who owns the agent, what it is allowed to do, how its access changes over time and when it should be removed. Both are necessary, but identity governance addresses the full operational lifecycle.

Q: When should organisations treat an AI agent as a high-risk identity?

A: Treat an AI agent as high-risk when it can move data, trigger production actions, or access multiple systems without direct human oversight. The more environments it spans, the more likely a single misconfiguration can create broad blast radius. In those cases, continuous review is safer than static approval.

Technical breakdown

Why agent identity needs lifecycle control

AI agents are not just users with scripts. They have creation events, credentials, permissions, runtime behaviour and eventual decommissioning requirements, which means they need lifecycle control just like other non-human identities. In practice, that lifecycle includes registration, approval, privilege assignment, rotation of underlying secrets or keys, monitoring, and retirement when the agent is no longer needed. Without those steps, agents accumulate standing access and become hard to distinguish from sanctioned automation. The technical risk is not only over-permissioning. It is identity drift, where an agent's original purpose no longer matches its current privileges or runtime scope.

Practical implication: Treat every agent as a lifecycle-managed identity, not an application feature.

What risk-based access control changes for autonomous agents

Risk-based access control adds context to decisions by using signals such as unusual behaviour, location, device state, or identity risk to decide whether access should continue. For agents, this is useful because their activity can change quickly and their actions can be difficult to predict from static policy alone. But the control only works if the telemetry is trusted and if policy can be enforced across every system the agent touches. A risk score inside one identity domain does not protect a token used in another cloud or a SaaS integration. The real architectural challenge is consistent enforcement across heterogeneous control planes.

Practical implication: Use behavioural signals to narrow access, but require cross-platform enforcement.

Why cross-environment discovery is the missing layer

Discovery is the foundation for governing AI agents because you cannot secure what you cannot enumerate. In distributed environments, agents may exist in cloud accounts, source-control workflows, chat platforms, SaaS automations and internal frameworks, each with its own permissions and audit trail. That fragmentation creates blind spots in ownership, credential lineage and data movement. A single platform can provide strong governance within its own boundary, but enterprise risk emerges when agents move across those boundaries. The security model therefore has to link identity, secrets, entitlements and behaviour into one inventory.

Practical implication: Build a cross-environment inventory before attempting fine-grained policy.

Threat narrative

Attacker objective: The objective is to abuse an autonomous identity's standing access to reach sensitive systems or data across multiple environments.

1. Entry occurs when an AI agent is granted access through a trusted automation path such as a workflow, connector or service credential.
2. Escalation follows when the agent accumulates broader entitlements than its original task requires and can call additional APIs or systems.
3. Impact is reached when the agent can move data, trigger actions or expose secrets across environments without unified oversight.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agents are becoming a new class of non-human identity, and IAM models built for human users are too narrow to govern them. Agents have permissions, lifecycle events, data access and behavioural variability, which makes them operational identities rather than simple automations. Security teams that treat them as scripts will miss privilege creep, drift and audit gaps. The practical conclusion is that agent governance must sit inside the identity programme, not beside it.

Microsoft Agent 365 sharpens the industry conversation, but it also exposes the limits of single-platform governance. Any identity control plane that only covers one ecosystem leaves the enterprise with incomplete visibility once agents span clouds, SaaS and engineering pipelines. That is not a product critique, it is a governance fact. Practitioners should assume multi-environment sprawl and design for it from the start.

Identity blast radius is the right concept for agent risk. The question is no longer whether an agent is authenticated. It is how far it can move, what it can touch and how quickly its privileges can be reduced when behaviour changes. That framing pushes teams toward least privilege, continuous review and faster decommissioning. The discipline shifts from access granting to blast-radius containment.

Lifecycle management, not one-time provisioning, is what makes agent identity defensible. If an agent can be created quickly but not retired cleanly, the organisation inherits the same accumulation problem seen with service accounts and secrets. Strong governance therefore depends on owner assignment, approval gates, revocation paths and periodic recertification. Teams should measure how quickly they can remove an agent, not only how quickly they can deploy one.

Cross-environment visibility is now a prerequisite for meaningful NHI governance. The enterprise does not need another isolated identity silo. It needs a continuous view that links agent identity, credentials, entitlements and runtime behaviour wherever the agent operates. Without that, policy becomes fragmented and incident response becomes guesswork. The practitioner takeaway is to govern the whole path, not a single platform boundary.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• For a broader governance baseline, see NHI Lifecycle Management Guide for lifecycle controls that help reduce identity sprawl across environments.

What this signals

The practical signal for security programmes is that AI agent governance is converging with the wider NHI problem space. With 1 in 4 organisations already investing in dedicated NHI security capabilities, according to The State of Non-Human Identity Security, the question is no longer whether to build controls, but how quickly those controls can span clouds, SaaS and automation pipelines.

Identity blast radius: the useful mental model here is not just whether an agent is approved, but how far a compromised or misconfigured agent can reach before controls intervene. That pushes programmes toward tighter ownership, faster revocation and better linkage between secrets, entitlements and runtime behaviour.

Teams that are still organising controls around individual platforms will keep finding gaps when agents cross tool boundaries. The stronger programme pattern is to align agent governance with the broader NHI lifecycle, then extend monitoring and recertification across every environment where the agent can act.

For practitioners

• Map every agent to an accountable owner Create a register that ties each autonomous workflow to a human owner, business purpose and retirement date. Require this before granting production access, and review it alongside service accounts and other non-human identities.
• Inventory agent credentials across all environments Track tokens, API keys, certificates and delegated access used by agents in cloud accounts, SaaS tools and CI/CD systems. Link those secrets to the systems they can reach so hidden privilege does not accumulate.
• Apply least privilege at the workflow level Scope access to the specific task, dataset and runtime needed by each agent. Reassess permissions whenever the agent's purpose, prompt, integration or destination systems change.
• Add continuous review for agent behaviour Monitor action patterns, unusual tool use and cross-system reach, then revoke or step up controls when behaviour shifts outside the approved operating range. Pair this with periodic recertification of standing access.

Key takeaways

• AI agents should be governed as non-human identities because they carry permissions, secrets and operational blast radius.
• Single-platform control planes improve local governance, but they do not solve the enterprise problem of cross-environment agent sprawl.
• The most effective control strategy combines discovery, ownership, least privilege and lifecycle management across every environment an agent can touch.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause if it is compromised, misused or over-permissioned. For AI agents and other non-human identities, it is shaped by scope, entitlements, runtime access, secrets and the number of systems the identity can reach before controls intervene.
• Cross-Environment Discovery: Cross-environment discovery is the practice of finding and inventorying identities, secrets and entitlements across clouds, SaaS platforms, code systems and internal tooling. It is a foundational control because governance cannot be applied consistently until security teams can see where identities exist and what they can access.

What's in the full article

Microsoft's full article covers the operational detail this post intentionally leaves for the source:

• A feature-by-feature walkthrough of Agent 365 identity primitives, including Agent IDs, policy templates and auditability
• Examples of how Agent 365 is intended to work inside Microsoft environments and Entra-integrated systems
• The article's own positioning on agent registry, unified dashboards and risk-adaptive controls
• The vendor's framing of why its control plane matters for Microsoft-centric deployments

👉 The full Microsoft article outlines the control plane features and Microsoft-specific governance scope

Deepen your knowledge

AI agent governance and non-human identity lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for distributed agents across clouds and SaaS, it is worth exploring.