Notifications
Clear all
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.
NHIMG editorial — based on content published by Descope: Build Identity-Aware Agents With Azure AI Foundry and Descope
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Descope's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step setup for Descope projects, clients, resources, and connections across Azure AI Foundry and MCP tools
- Code-level examples for token exchange, resource-level scopes, and per-run Authorization headers
- Configuration guidance for CIBA, dynamic client registration, and approval flows for headless agents
- Operational logging and audit behaviour for issuance-time policy decisions and approval outcomes
👉 Read Descope's analysis of Azure AI Foundry and agent identity governance →
Identity-aware AI agents: where directory identity stops and policy starts?
Explore further
12/06/2026 11:44 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity-aware AI agents expose the limits of directory-granted access
