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

At a glance

What this is: This is an analysis of how Azure AI Foundry and Entra handle agent identity, and where per-request policy, vaulting, and approvals remain outside the native model.

Why it matters: It matters because IAM teams need to separate directory identity from issuance-time authorisation when agents act across tools, tenants, and approval boundaries.

By the numbers:

• Only 44% have implemented any policies to govern AI agents, despite 92% agreeing that governing them is critical to enterprise security.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Descope's analysis of Azure AI Foundry and agent identity governance

Context

Identity-aware agents are changing the control boundary for IAM teams. A directory entry can say what an agent is and whether it is registered, but that does not answer the harder question of what it may do on a specific request, for a specific user, against a specific resource. That distinction matters most when the agent can reach multiple tools and the token it carries is broader than the action the user intended.

Azure AI Foundry and Microsoft Entra give strong native identity primitives for agents inside Microsoft infrastructure, but the article shows that pre-granted scopes, app roles, and directory governance do not by themselves solve issuance-time authorisation, credential vaulting, or out-of-band approval. For practitioners, the issue is not whether agents have identities. It is whether the identity layer can enforce per-request policy across the full delegation chain.

Key questions

Q: How should security teams govern agent access when directory identity is not enough?

A: They should treat directory identity as the starting point, not the decision. The real control must happen at token issuance, where the system can evaluate the user, tenant, resource, and requested scope together. That keeps the agent registered for visibility while preventing broad, pre-granted access from becoming the default.

Q: Why do AI agents create problems for traditional access review models?

A: Because traditional reviews assume privileges persist long enough to be observed, certified, and recertified. Agents often operate through short-lived, request-specific tokens and federated tools, so the meaningful decision happens before the token exists. If the review cycle only sees standing identity, it misses the actual authority used at runtime.

Q: How can teams reduce secret exposure in agent workflows?

A: Use a vault for third-party OAuth tokens and static API keys, then retrieve credentials only when a tool call needs them. That keeps raw secrets out of the model context and out of application code. The goal is not just storage, but controlled retrieval with narrow scope and short lifetime.

Q: Who is accountable when an agent performs a sensitive action without adequate approval?

A: Accountability should sit with the team that defined the approval policy, the team that integrated the agent, and the owner of the downstream system that accepted the call. If those responsibilities are split, the organisation needs a single evidence trail that ties the user, the agent, the request, and the approval outcome together.

Technical breakdown

Directory identity vs issuance-time authorisation

A directory identity tells an IAM system that an agent exists, what tenant it belongs to, and what baseline permissions have been consented or assigned. Issuance-time authorisation is different: it evaluates the request context before a token is minted, so the decision can reflect the invoking user, the target resource, the requested scope, and tenant policy. If that check happens only after a token exists, the token itself becomes the source of authority rather than the policy decision that should have shaped it. That gap is why directory governance and request-level control are not interchangeable.

Practical implication: Treat directory registration as inventory, not authorisation, and enforce per-request policy at token issuance.

MCP clients, resource servers, and the missing policy layer

Model Context Protocol clients and resource servers create a delegation chain that spans an agent, its tools, and the systems those tools reach. In that chain, authentication proves who is talking, but authorisation must still decide what each call can do. The article highlights two missing primitives in the native stack: dynamic client registration for self-registering MCP clients and CIBA for out-of-band approval. Without those, teams often push policy down into each API, which fragments governance and makes review and logging inconsistent across the fleet.

Practical implication: Centralise request policy for MCP and backend APIs instead of duplicating scope logic in every downstream service.

Credential vaulting across runtimes and services

An agent that touches Microsoft Graph, Salesforce, internal APIs, and other services will accumulate different credential forms, including OAuth tokens and static API keys. Vaulting matters because long-lived secrets should not sit in an agent runtime or be exposed to model context. The technical control is not just storage. It is controlled retrieval at call time, coupled with scoped exchange so the agent receives only the credential needed for that action. That pattern reduces secret exposure and limits cross-service reuse when the agent moves between runtimes.

Practical implication: Use a credential vault and scoped token exchange for every non-Microsoft service the agent reaches.

NHI Mgmt Group analysis

Directory-granted agent identity is not the same as request-granted authority. The article exposes a governance split that many identity programmes still blur: an agent can be registered, governed by Conditional Access, and federated through a directory without being authorised for a specific action at the moment of use. That is a control boundary problem, not a product feature issue. Practitioners should treat directory identity as standing context and issuance-time policy as the real decision point.

Issuance-time policy is the named control gap this architecture makes visible. Pre-consent and app-role assignment were designed for stable, human-paced authorisation events. That assumption fails when an agent needs to decide per request, because the meaningful security question is not whether the agent belongs in the directory, but whether this call should carry this scope for this user against this resource. The implication is that IAM teams must reframe permission as a transaction, not a registration state.

Credential vaulting becomes a governance requirement once agents cross runtimes. The moment an agent can call Microsoft services, third-party SaaS, and internal APIs in one workflow, static secrets and long-lived OAuth tokens stop being tolerable as ambient runtime material. The article shows why a single directory cannot also be the secret store for everything else the agent touches. Practitioners need a separate control plane for credential retrieval and lifecycle handling across the fleet.

CIBA and DCR matter because agents create approval and registration events on demand. Headless agents do not fit the older assumption that every client is pre-registered and every approval can be captured through a browser redirect. When an action needs human confirmation or a client needs to appear dynamically, those missing protocol primitives become governance blockers, not convenience gaps. Security teams should evaluate whether their current identity stack can represent both asynchronous approval and self-registration without manual workarounds.

Identity-aware agents force IAM, IGA, and PAM to converge at the token boundary. This is no longer just an access-management question and not just an agent platform question. When one layer grants standing identity, another layer governs per-request scope, and a third layer approves sensitive actions, the control model only works if the audit trail preserves all three decisions together. Practitioners should design for unified evidence, not separate logs that cannot explain a single agent action.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader control baseline, read OWASP Agentic AI Top 10 alongside our agent governance analysis to map request-level policy and tool-risk boundaries.

What this signals

Request-level policy will become the control plane that separates visible agent identity from usable authority. Teams that keep relying on pre-granted scopes will find that directory governance tells them who the agent is, not what it can safely do in a given transaction. The operational signal to watch is whether your approval, scope, and audit data can be tied back to a single issuance event.

Per-request decisioning is the named capability gap now surfacing in production agent deployments. The article makes clear that the next maturity step is not more agent registration, but tighter control over what gets minted into each token. Organisations with multiple runtimes should expect pressure to unify their policy logic across Microsoft and non-Microsoft toolchains, especially where MCP is involved.

With 52% of companies able to track and audit the data their AI agents access, the other 48% are already operating without a defensible investigation trail. That gap will force IAM, IGA, and PAM teams to converge on shared evidence models rather than separate logs that cannot explain one agent action across systems.

For practitioners

• Separate registration from authorisation: Record every agent in the directory, but move the actual allow or deny decision to issuance time using user, tenant, resource, and scope as inputs. Do not treat app role assignment as the final control for a live request.
• Centralise policy for agent token minting: Define request-level rules once and apply them before tokens are issued, rather than replicating scope checks in each MCP server or backend API. This keeps approval logic consistent across runtimes and reduces policy drift.
• Vault non-Microsoft credentials outside the runtime: Move third-party OAuth tokens and static API keys into a controlled vault, then fetch them at call time with scoped exchange. Do not leave raw secrets in agent memory, tool code, or deployment variables.
• Add out-of-band approval for sensitive actions: Use an approval flow for account changes, payments, or other high-risk operations that the agent initiates without a browser session. The control should produce a durable approval record tied to the token that was issued.
• Audit the delegation chain end to end: Check whether the agent identity, the invoking user, the granted scope, and the downstream tool call can be reconstructed in one evidence set. If those signals live in separate systems, you will struggle to explain or prove why an action occurred.

Key takeaways

• Directory identity for agents does not solve the harder problem of per-request authority, especially when the user, resource, and scope all vary at runtime.
• The strongest signal in the article is the split between registration and issuance, which shows why static consent and app roles are not enough for modern agent governance.
• Practitioners should move policy, vaulting, and approval decisions closer to the token boundary if they want evidence and control to line up.

Key terms

• Issuance-time authorisation: Issuance-time authorisation is the decision made before a token is minted, when the system can evaluate the user, agent, resource, tenant, and requested scope together. It is stronger than static consent because it governs the specific action being requested, not just the identity standing behind it.
• Agentic identity hub: An agentic identity hub is a control layer that manages identities for AI agents across runtimes, tools, and services. It typically combines directory functions, policy decisions, token issuance, credential vaulting, and audit trails so that one agent can be governed consistently even when it touches multiple platforms.
• Credential vault: A credential vault stores secrets, OAuth tokens, and API keys outside the runtime where an agent executes. It reduces exposure by letting tools fetch credentials only when needed, rather than embedding long-lived secrets in code, memory, or model context.
• 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 security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Descope: Build Identity-Aware Agents With Azure AI Foundry and Descope. Read the original.