Topic starter
12/06/2026 9:34 pm
TL;DR: Azure AI Foundry and Entra can register agents, apply directory controls, and federate third-party identities, but per-request authorisation, credential vaulting, and approval flows still sit outside the native stack, according to Descope. The governance gap is not agent identity itself, but the assumption that pre-granted scopes are enough for dynamic agent behaviour.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “Build Identity-Aware Agents With Azure AI Foundry and Descope”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Directory identity helps register and track AI agents, but it does not by itself decide what a specific request should be allowed to do.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
12/06/2026 11:44 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity-aware AI agents expose the limits of directory-granted access
This post was modified 7 days ago by NHI Mgmt Group