Agent 365 shows why identity is not access governance for AI agents

At a glance

What this is: Agent 365 improves AI agent identity inside Microsoft, but the core finding is that identity inventory still does not equal access governance.

Why it matters: IAM teams must distinguish between knowing what an agent is and controlling what it can do, because the same gap also affects NHI and human governance when ownership, scope, and runtime privilege drift.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and a further 47% have only partial visibility.

👉 Read Oasis Security's analysis of Agent 365 and AI agent access governance

Context

Agent identity is the record that says who or what the actor is. Access governance is the discipline that controls what that actor can reach, when it can act, and whether those permissions still match business intent. In Microsoft-centric environments, Agent 365 raises the identity baseline for AI agents, but it does not close the gap between an agent being known and an agent being governed.

That distinction matters because AI agents are now being treated as non-human identities alongside service accounts, tokens, and API-linked workflows. Once agents can inherit scopes, carry connector credentials, or call downstream tools, the governance problem shifts from registration to runtime control. The starting point described in this article is typical for enterprises trying to modernise identity controls without rebuilding access policy for autonomous software actors.

Key questions

Q: How should security teams govern AI agents beyond identity registration?

A: Teams should govern AI agents the same way they govern other high-risk NHIs: by separating identity from entitlement, mapping downstream credentials, and continuously reviewing what the actor can actually do. A registry is a starting point, not proof of control. The real question is whether the agent’s current access still matches its approved purpose and owner.

Q: Why do AI agents complicate NHI access reviews?

A: AI agents complicate access reviews because their privileges can change through new tools, widened scopes, and inherited permissions long after provisioning. That means a periodic review can be technically correct and still miss the current risk. Review processes need runtime evidence, not just directory entries, if they are going to stay relevant.

Q: What breaks when an agent identity layer does not include access governance?

A: What breaks is the assumption that visibility equals control. The agent may be named, logged, and inventoried, yet still hold broad OAuth grants, connector permissions, or secrets that determine its actual blast radius. In practice, that leaves teams with a clean record and an uncontrolled actor.

Q: How do organisations compare agent identity platforms with access governance needs?

A: They should compare them on control scope, not branding. Identity platforms are useful when the problem is discovery, ownership, or sign-in policy. Access governance is required when the problem is runtime privilege, downstream credentials, or tool misuse across multiple environments.

Technical breakdown

Agent identity versus access governance

An agent identity layer answers inventory questions: who created the agent, which system it lives in, and which policy hooks can see it. Access governance answers entitlement questions: what the agent can do, which downstream resources it can reach, and whether those permissions are still justified at runtime. The architectural mistake is to treat these as the same control plane. Identity without governance can still leave oversized OAuth grants, inherited user scopes, and permanent connector access in place, even when the agent is visible in the directory.

Practical implication: separate agent inventory from entitlement control and review both as distinct governance functions.

Downstream credentials and connector scope

Most agent risk sits below the directory object. Once an AI agent is allowed to use OAuth grants, API keys, MCP tokens, or vault secrets, its effective reach is determined by the tools it can call and the scopes those tools inherit. That creates a hidden control plane where the agent may appear tightly governed while still holding broad operational access through connectors, delegated permissions, or long-lived secrets. Registries usually do not show how much privilege actually flows through those downstream links.

Practical implication: map every agent to its downstream credentials and tool scopes before approving production use.

Why runtime posture matters more than static registration

Static registration captures a moment in time. Agent posture is the moving picture: scope drift, owner changes, tool additions, and inherited permissions that no longer match the original approval. That is why a registry can be accurate and still miss the real risk. In access governance terms, the important question is not whether an agent exists, but whether its current behaviour still fits its approved business function and privilege boundary.

Practical implication: add continuous drift detection for agent behaviour, ownership, and permissions rather than relying on one-time onboarding checks.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Identity visibility is not the same as access governance, and that gap is now the central NHI problem for AI agents. A directory can tell you an agent exists, but it cannot tell you whether the agent still needs its current scopes, connectors, or delegated credentials. That is why agent identity layers help with inventory while leaving the harder governance question unresolved. Practitioners should treat visibility as a prerequisite, not a control outcome.

Agent registries create a false sense of completeness when downstream access lives outside the registry. OAuth grants, API keys, MCP tokens, and vault secrets determine the real blast radius, not the identity object alone. This is the named concept that matters here: downstream access shadowing. It occurs when the visible agent identity looks controlled while its effective privilege is spread across unseen tool and credential relationships. The practitioner conclusion is simple: if the entitlement plane is not mapped, the governance plane is incomplete.

AI agents are non-human identities with faster privilege drift than traditional service accounts. Ownership changes, tool proliferation, and inherited scopes can change the access profile long after provisioning. That makes AI agents operationally closer to high-churn NHI estates than to stable directory identities. Teams should stop assuming that a clean identity record means the actor remains within policy.

Microsoft-centric control planes can reduce local blind spots, but they do not solve multi-plane governance. Once agents exist across endpoints, SaaS, source control, and non-Microsoft runtimes, the identity problem becomes cross-domain. The implication for the field is that access governance is becoming the durable discipline, while identity registration becomes only one input to it. Practitioners need cross-plane governance models that can follow the actor, not just the directory record.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage.
• The broader control lesson is covered in 52 NHI Breaches Analysis, which shows how visibility failures turn into persistent access exposure.

What this signals

Downstream access shadowing is the pattern to watch as AI agents spread across enterprise estates. Once the identity plane and the entitlement plane diverge, the programme needs continuous correlation across directories, vaults, connectors, and execution logs, not just better onboarding of new actors. With 92% of organisations exposing NHIs to third parties, the governance boundary is already wider than most teams assume.

Agent governance will increasingly look like NHI governance with faster churn. Ownership changes, inherited scopes, and tool sprawl mean that periodic certification alone will miss material drift between review cycles. Teams should prepare for a model where runtime access posture becomes the operational source of truth, supported by guidance in the Ultimate Guide to NHIs and broader control patterns described in 52 NHI Breaches Analysis.

For practitioners

• Separate agent inventory from entitlement review Build a control process that reviews agent identity, downstream scopes, and tool access as three different approval artifacts. A registry should not be treated as evidence that the agent is safe to run.
• Map downstream credentials to every production agent Track OAuth grants, API keys, MCP tokens, connector permissions, and vault secrets for each agent so the actual blast radius is visible before go-live.
• Re-certify agent ownership and purpose on a fixed cadence Require a named business owner and a current use case for every agent, then revoke access when the owner changes or the business purpose no longer matches.
• Detect drift across tools, scopes, and execution paths Monitor for new connectors, widened scopes, and agent-to-agent delegation so runtime behaviour can be compared with approved posture, not just initial registration.

Key takeaways

• AI agent identity is only the first layer of control, because access governance determines the real blast radius.
• Visibility gaps remain severe across non-human identity estates, so registry-based oversight cannot be treated as complete governance.
• Practitioners should map downstream credentials and monitor drift continuously if they want agent controls to stay aligned with actual behaviour.

Key terms

• Agent Identity: An agent identity is the directory or platform record that establishes which software actor exists and who owns it. In practice, it supports discovery, policy attachment, and auditability, but it does not by itself limit what the agent can reach or do. Governance still depends on entitlement control and runtime verification.
• Access Governance: Access governance is the set of controls that determine what an identity can do, when it can do it, and whether those permissions remain justified. For AI agents and other NHIs, it includes entitlement review, ownership validation, drift detection, and control of downstream credentials that actually carry privilege.
• Downstream Credentials: Downstream credentials are the secrets, tokens, keys, and delegated permissions that an identity uses to operate beyond its own directory record. They matter because they often define the real blast radius of an AI agent or service account, especially when the visible identity layer looks well managed.
• Posture Drift: Posture drift is the change between what an identity was approved to do and what it can do today. For agents, that drift can come from new connectors, widened scopes, inherited permissions, or ownership changes, making periodic reviews insufficient without continuous observation.

Deepen your knowledge

Agent identity and access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI agents alongside service accounts and secrets, it is worth exploring.

This post draws on content published by Oasis Security: AI Agent Identity (Agent 365) Meets Access Governance. Read the original.