Identity-aware AI agents expose the limits of directory-granted access

At a glance

What this is: This is an analysis of identity-aware AI agents and the finding that directory-granted access does not cover per-request policy for dynamic agent behaviour.

Why it matters: It matters because IAM teams and identity architects need to distinguish directory standing from issuance-time authorisation when agents act on behalf of users, tools, and tenants.

Context

Identity-aware agents are software identities that can be registered in a directory, authenticated, and governed, but still make use of downstream tools and scopes at runtime. The governance gap here is not whether the agent exists in Entra or another directory, but whether pre-granted access can safely represent per-request intent when an agent acts on behalf of different users and tenants.

In this model, directory identity answers standing questions such as who the agent is and what it was consented to hold. Issuance-time policy answers the harder question of whether that specific request should receive those privileges at all. For IAM and NHI programmes, that distinction determines where the control plane ends and where application policy must begin.

Key questions

Q: What breaks when directory identity is treated as enough for AI agent authorisation?

A: Directory identity breaks as a governance boundary when teams assume registration and standing scopes are sufficient for dynamic agent behaviour. The agent may be known to the directory but still make request-by-request decisions that need separate policy. That creates over-broad access, weak auditability, and the wrong trust model for delegated execution.

Q: Why do identity-aware agents need issuance-time policy instead of only app roles?

A: Because app roles and group assignments describe standing entitlement, not the specific context of a single request. If the same agent can act for different users or tenants, the real decision is whether that request should receive the token at all. Issuance-time policy lets teams bound scope before the token exists.

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: What is the difference between directory registration and runtime authorisation for agents?

A: Directory registration establishes identity and standing access, while runtime authorisation decides what a specific request may do right now. An agent can be validly registered yet still need denied scopes, step-up approval, or narrower resource access for a given invocation. Treating the two as the same creates governance blind spots.

Technical breakdown

Directory identity versus issuance-time policy

A directory entry records identity, registration, and standing access, but it does not evaluate every runtime request. In the article’s model, Entra assigns the agent an identity and lets Conditional Access govern sign-in, while the actual scope decision still happens elsewhere. This is a classic separation between authentication, consent, and authorisation. When an agent can act on behalf of different users, directory group membership and app roles are too coarse to decide what a single request should receive. The practical design choice is whether token contents are fixed ahead of time or evaluated at the moment the token is minted.

Practical implication: move request-specific scope decisions to issuance time rather than treating directory membership as sufficient authorisation.

Why credential vaulting matters for agent tool use

Agents commonly need access to third-party OAuth tokens, static API keys, and backend resources that should never appear inside model context. The article’s distinction is that a directory can identify the agent, but it does not securely hold every outbound credential the agent will need across tools and runtimes. A credential vault changes the failure mode by removing long-lived secrets from the environment and exchanging them only when a tool call is made. That matters because agentic workflows expand the number of places where secrets can leak, persist, or be reused across tasks.

Practical implication: vault tool credentials separately from agent identity so secrets are fetched only at call time.

Why CIBA and MCP DCR fill the missing control points

Headless agents need more than sign-in and directory registration. The article points to two gaps: no out-of-band approval primitive for sensitive actions and no Dynamic Client Registration for self-registering clients in the native stack. CIBA gives a way to pause a sensitive action until an external approver consents, while DCR lets MCP clients register without manual pre-creation. These are not cosmetic features. They define whether a governance model can handle asynchronous approval, delegated execution, and standards-based tooling without pushing every exception into custom application code.

Practical implication: require approval and client-registration controls wherever agents can initiate sensitive or self-service tool access.

Threat narrative

Attacker objective: The attacker’s objective is to obtain and reuse over-scoped delegated access so the agent can perform actions beyond the intended request boundary.

1. Entry begins when an agent is registered in the directory and granted standing access through consent or app role assignment.
2. Escalation occurs when the agent’s runtime request can inherit more scope than that specific action should receive, because authorisation is decided ahead of time.
3. Impact follows when downstream APIs trust the token as issued and the wrong scope is applied to the wrong request or user context.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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

NHI Mgmt Group analysis

Pre-granted scope is the wrong unit of governance for identity-aware agents: The article shows that directory identity can prove who or what an agent is, but not what that agent should do on a specific request. That is a different governance problem, and it sits closer to token issuance than to directory registration. For identity programmes, the implication is that standing access is no longer enough to describe an agent’s real authority.

Directory-granted access was designed for stable authorisation contexts, not request-variable behaviour: The model works when access can be assigned once and reused many times. That assumption fails when the same agent can act for different users, tenants, and tools inside a single workflow. The implication is that agent governance must be measured against runtime context, not only directory membership.

Identity-aware agent governance is becoming a policy plane problem, not a directory problem: Entra-style identity still matters for registration, federation, and Microsoft resource access, but the article makes clear that it does not close the loop on per-request scope ceilings. That gap will push more teams toward issuance-time policy, vaulting, and approval layers that sit above the runtime. Practitioners should treat directory control as necessary but incomplete.

Cloud-neutral control planes are becoming the practical answer to multi-runtime agent fleets: The article’s value is not the vendor pairing, but the signal that one cloud directory will not govern every agent runtime. As agents move across Foundry, Bedrock, Vertex AI, and local MCP tooling, governance has to follow the request, not the platform. The implication is that identity architecture must stop assuming a single runtime owns the whole trust chain.

Identity-aware agents expose an assumption collapse in human-style access governance: Access review, group assignment, and pre-consent were designed for access that persists long enough to be reviewed and recertified. That assumption fails when a request is generated dynamically and policy must be decided before the token exists. The implication is that practitioners must rethink review timing, not just add more review steps.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Identity-aware agent governance moves the decision point closer to token issuance: Teams should expect directory controls to remain necessary but insufficient once an agent can act on behalf of multiple users or tenants. The practical shift is from broad standing entitlement toward request-scoped policy, especially for systems that mix MCP tools, external APIs, and delegated user context.

Policy planes will matter more than agent directories: Once agents cross runtime boundaries, the question is no longer only who registered the agent. It becomes what the agent is allowed to do in this exact call, with this exact user, against this exact resource. That pushes architecture toward issuance-time controls, vaulting, and approval workflows rather than directory-first governance alone.

For practitioners

• Define issuance-time policy for agent requests Separate directory standing from request-level authorisation so scopes are evaluated when the token is minted, not after the agent already holds broad access.
• Vault outbound credentials outside the agent runtime Keep third-party OAuth tokens and static API keys in a dedicated vault so the model context never sees long-lived secrets.
• Add out-of-band approval for sensitive actions Require an approval step for elevated operations that should not proceed on the agent’s first successful request, especially when human confirmation is part of the control design.
• Register and govern MCP clients explicitly Treat MCP clients as first-class identities with their own registration, scope boundaries, and lifecycle records instead of letting each tool invent its own trust rules.

Key takeaways

• Directory identity helps register and track AI agents, but it does not by itself decide what a specific request should be allowed to do.
• The real control gap is at issuance time, where scope, user context, and tool access must be evaluated before a token is created.
• Credential vaulting and out-of-band approval are the controls that keep agent behaviour from overrunning pre-granted access assumptions.

Key terms

• Directory Identity: The directory record that establishes what an agent is, how it is registered, and what standing access it has. In agentic environments, directory identity is necessary for administration and audit, but it is not enough to decide whether a specific runtime request should be authorised.
• Issuance-time policy: Issuance-time policy is the practice of evaluating who is asking, what they may request, and which scopes are allowed before a token is minted. For agents, this is the control point that prevents excess privilege from ever becoming an active credential.
• Credential Vaulting: Credential vaulting stores privileged secrets in a controlled system rather than distributing them to users or embedding them in workflows. The security value comes from reducing direct exposure, supporting revocation, and creating a single governance point for high-risk credentials.
• CIBA: CIBA is a backchannel approval pattern for situations where the user is not in a browser at the point of decision. In identity programmes, it gives teams a way to capture out-of-band approval for sensitive actions without forcing the agent or application to fake a normal interactive login flow.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.