2938 Members
Join Permit's SlackWhen Microsoft published the Entra Agent ID framework, it marked something worth pausing on: enterprise IAM is now treating AI agents as first-class identities, complete with their own registration, blueprints, Conditional Access controls, lifecycle governance, and directory-native audit records. That is genuine progress. Security teams reviewing the capability tend to follow up with a question that the framework does not fully answer: does having an identity mean the agent is authorized to act?
The answer is no, and the gap between those two things is where most agentic risk actually lives. An agent can hold a valid Entra-issued token, pass Conditional Access checks, and still be doing something it shouldn't. The action might technically fall within its OAuth grant scope but be contextually wrong — accessing a resource the delegating user never consented to in this context, executing a high-risk tool invocation without required human approval, or continuing a session after the authorizing user's access was revoked thirty seconds ago. Identity confirms who or what the caller is. Authorization is a different question entirely.
This article maps where Entra Agent ID, SD-JWT agent identity standards, OAuth, and A2A protocols stop — and what the runtime authorization layer needs to supply. The architecture pattern covers MCP tool-call enforcement, policy decision points, human delegation binding, mid-session revocation, and the audit schema that actually satisfies compliance forensics.
It is worth being precise about definitions before applying them, because most of the confusion in this space comes from treating agent identity as equivalent to machine identity.
Agent identity is a cryptographically verifiable enterprise identity that represents an AI agent as a distinct principal, so it can authenticate, be governed, and be audited. Agent authorization is the runtime policy decision about whether that identified agent may perform a specific action on a specific tool or resource in the current context. An MCP gateway is the policy enforcement point that intercepts Model Context Protocol tool calls and enforces allow, deny, or step-up decisions before tool execution reaches the target server. Human-to-agent delegation is the explicit binding that records which human authorized an agent to act, within what scope, purpose, and time boundary.
Human identity carries employment role, user context, and personal accountability. Service and workload identities represent application processes with deterministic, predictable behavior — a service doesn't make judgment calls about which API to call next. Machine identities represent hardware endpoints. Agent identity is different from all three because agents reason, plan, and select actions dynamically based on context. A service principal calling a payment API does so because code tells it to. An agent calling a payment API might do so because it inferred from an email thread that this was the right next step — and that inference might be wrong, manipulated, or simply outside the scope of what the delegating user intended.
That behavioral autonomy is not an abstract difference. It changes the risk profile in a way that makes existing workload identity controls insufficient. A service identity with a static set of permissions is predictable enough that coarse OAuth scopes can cover it reasonably well. An agent that can chain tool calls, respond to prompt-injected instructions, and take irreversible actions at production scale needs something more contextual at enforcement time.
The Microsoft Entra Agent ID documentation positions agent identities as first-class principals in the enterprise directory, and the capabilities it brings are foundational. Agent blueprints let IAM teams govern classes of agents rather than managing hundreds of individual registrations — you define the blueprint once, instantiate agents from it, and inherit the governance model automatically. Conditional Access can be applied at the blueprint level, so you can say that agents in the "customer-data processor" class require compliant contexts before they receive tokens at all. Lifecycle governance covers the full arc: create, update, disable, revoke. Directory-native auditing captures sign-in and identity events for every agent, which is exactly what compliance teams need to start answering "what agents existed, and what did they authenticate to?"
The Azure Foundry agent identity documentation adds implementation depth around how agent identities participate in runtime token exchange and tool authentication flows — specifically how a Foundry-hosted agent uses its managed identity to request access tokens for downstream tools and APIs.
Alongside enterprise IAM platforms, the IETF is working on portable, standards-based agent identity through SD-JWT techniques. The IETF SD Agent draft defines an SD-Card format for agents — a selective-disclosure credential that lets an agent present only the claims a verifier needs rather than exposing its full capability and metadata profile. This matters particularly in federated or cross-organization agent interactions, where over-disclosing agent capabilities to an external system can itself become a risk surface. A2A (the Agent-to-Agent protocol) uses discovery mechanisms compatible with this format to let agents find and negotiate with each other across trust boundaries.
Both streams solve authentication, governance, and discovery well. Neither one answers the question the IETF SD Agent draft explicitly raises: the security considerations section states that agent discovery and identity context do not automatically carry authorization for MCP tool invocations. That context-does-not-equal-permission boundary is the point this article is built around.
Most MCP server implementations correctly validate incoming tokens. They check the issuer, verify the signature, confirm the audience claim, and inspect OAuth scope strings. What they generally do not do is evaluate whether the identified agent, acting for the specific user who delegated to it, with the specific intent on record, should be allowed to perform this exact action on this exact resource at this exact moment under current conditions.
The distinction matters because OAuth scopes are coarse and mostly static. A scope like calendar:read was sufficient when the caller was a first-party app with predictable behavior. In an agentic context, a scheduling agent with calendar:read might be operating to prepare a summary for its delegating user, or it might be responding to an instruction injected via a malicious document it processed five tool calls ago. The scope does not know the difference. A runtime authorization decision can.
The factors that make a tool-call safe or unsafe in an agentic context include: who delegated the task, whether that delegation is still active and within its intended scope, whether the agent's stated intent is consistent with the specific action being requested, the sensitivity and classification of the tool and resource being targeted, current risk signals like anomalous session behavior or velocity, and whether this action category requires human approval before proceeding. None of these factors are captured in a token validation check or a scope string. They require a decision made at action time with live context.
The framing that helps here is to treat MCP authentication and MCP authorization as two separate control stages rather than one. Authentication establishes identity. Authorization evaluates policy. The gap between them is not a deficiency in Entra Agent ID or SD-JWT — those were never designed to make action-time tool-call decisions. Filling the gap requires an additional enforcement layer.
A well-structured policy decision for an agent tool call needs to evaluate more than the bearer token. At minimum, the input envelope fed to a policy decision point should include the following components.
The agent identity itself: issuer, subject, blueprint or class identifier, tenant, and any trust-level attributes from the identity credential. The human delegator: which user authorized this agent, whether that delegation is explicit and documented, whether it is still within its validity window, and whether the scope of this specific tool invocation falls within what the user actually consented to. The stated intent or task identifier: what objective was the agent given, and is the tool being called consistent with that objective or an unexpected deviation. The agent's trust level: whether this is an internally certified agent running in a controlled environment versus a third-party plugin of unknown provenance. The tool, action, and resource being targeted: the MCP tool name, the specific method, the target resource identifiers, the data classification of what will be read or written, and the deployment environment. Ambient risk context: current session posture, anomaly signals, time of operation, network provenance, and any prior failures or step-up states in this session.
The practical power of this model becomes clear with concrete examples. A scheduling agent should be able to read calendars for people it's been authorized to schedule for. It should not be able to export all executive calendars to an external endpoint, even if its OAuth grant technically includes calendar:read — that action exceeds the scope of what any reasonable delegation would cover. A payment agent might be authorized to initiate transfers below a defined threshold without human review, but invoking the same tool for a transfer that exceeds that amount should require an in-session approval step before proceeding. An agent operating on behalf of a user whose access has since been revoked should not be able to continue executing tool calls that depend on that user's authority — the revocation should propagate to running sessions within seconds, not minutes.
These are runtime authorization and tool-call authorization decisions. Each one requires evaluating a policy against a live context, not checking a scope claim that was set when the OAuth grant was issued.
A focused enforcement architecture places an MCP gateway at the enforcement boundary — a dedicated policy enforcement point that intercepts every tool call before it reaches any MCP server.
In this pattern, the agent authenticates via Entra Agent ID or an equivalent OAuth-compatible identity provider and receives a token. The MCP gateway intercepts every subsequent tool invocation. For each call, it validates the token's signature, issuer, audience, and expiry, then assembles the authorization context: agent claims extracted from the token, the human-to-agent delegation binding from a delegation store, the intent or task identifier from the active session, tool and resource descriptors from the MCP protocol message, and any available risk signals. That context object is submitted to a policy decision point, which evaluates the applicable policy — expressed in OPA/Rego, Cedar, or an equivalent policy model — and returns an allow, deny, or allow-with-obligation verdict. The gateway enforces the verdict: pass the call through, return an authorization error, or pause the call and invoke an approval workflow before allowing it to proceed. Every decision is written to an immutable audit log.
Permit.io provides the authorization management layer in this architecture: policy lifecycle, role and relationship management for human-to-agent delegation, and decision APIs that the gateway queries per tool call. OPAL handles real-time policy and data propagation — when a delegation is revoked, a user's access changes, or a risk threshold is updated, OPAL pushes those changes to the policy engines within seconds, so revocation is effective mid-session rather than at the next login boundary.
High-risk tool categories — payments over threshold, production writes, privileged infrastructure operations, PII exports — benefit from a two-stage pattern: a policy pre-check to determine whether approval is required, followed by a just-in-time approval workflow that pauses the agent, notifies the appropriate approver, captures a reason-for-access statement, and resumes only after explicit confirmation. The approval event and its context become part of the audit trail.
The audit schema deserves explicit attention, because identity-only logs do not satisfy compliance forensics for agentic systems. Each audit record should capture the agent identifier and blueprint class, the human delegator identifier for the session, the intent or task identifier, the MCP tool name and method, the target resource and its classification, the policy decision with version and reason codes, the risk signals evaluated, and correlation identifiers for both the A2A interaction (if any) and the MCP session. The IETF SD Agent draft specifically recommends correlating A2A interaction IDs with MCP session data for audit completeness — a recommendation worth treating as a minimum bar. Investigators reconstructing what an agent did and why need all of these fields together. Identity alone tells them who called; it cannot tell them whether the action was policy-valid.
Enterprise IAM is correctly expanding to include agents as principals. The runtime authorization layer is what transforms that identity infrastructure from governance scaffolding into an actual enforcement mechanism. Identity is the beginning of trust, not the end of it.
Agent identity establishes what principal an AI agent is — its cryptographic credentials, registration record, lifecycle status, and governance class. Agent authorization is a separate runtime decision: given that we know who this agent is, should it be allowed to perform this specific action on this specific resource under current conditions? Identity is a prerequisite for authorization, but it does not substitute for it. An agent can be fully identified and still be attempting an action that exceeds its delegated scope or requires human approval first.
Entra Agent ID provides identity registration, blueprint-based governance, Conditional Access, lifecycle management, and directory-level auditing for sign-in events — all of which are foundational. What it does not provide is a per-tool-call authorization decision at MCP invocation time. The Entra Agent ID documentation covers identity and access management in the IAM sense; runtime authorization for individual tool calls requires an additional enforcement layer that evaluates action-time context against policy.
OAuth scopes express broad, static permission categories — they were designed for applications with predictable behavior calling well-defined APIs. In an agentic context, the same scope can cover legitimate operations and contextually inappropriate ones depending on who delegated the task, what the stated intent is, what resource classification is involved, and what ambient risk signals are present. A scope string cannot capture dynamic factors like whether a delegation is still active, whether this action exceeds the threshold requiring human approval, or whether the agent's behavior deviates from its declared intent. Runtime authorization fills these gaps by evaluating a richer context at decision time.
An MCP gateway acts as the policy enforcement point, intercepting every tool invocation before it reaches the target MCP server. The gateway validates the agent's token, assembles an authorization context that includes agent claims, human delegation binding, intent identifier, tool and resource descriptors, and risk signals, then submits this context to a policy decision point. The PDP evaluates the applicable policy — expressed in OPA, Cedar, or a similar model — and returns an allow, deny, or step-up verdict. The gateway enforces the verdict before the tool call proceeds, and logs the full decision context to an immutable audit record.
Human-to-agent delegation is the explicit binding between a human user's identity and an agent's authorization to act on their behalf, captured with scope boundaries, purpose, and validity constraints. In practice this means a delegation record that associates the delegating user's identifier, the agent identifier, the set of permitted tools and resources, the stated purpose or task context, and an expiry or revocation mechanism. When an agent makes a tool call, the authorization layer verifies that a valid delegation exists, that it covers this specific action, and that it has not been revoked — effectively treating delegation as a runtime policy input rather than a one-time grant.
The IETF SD Agent draft explicitly states that security context from agent discovery and SD-Card presentation does not automatically carry authorization for MCP tool execution. SD-JWT and SD-Card formats solve identity presentation and selective disclosure — they let an agent prove what it is to a verifier without over-disclosing. They do not evaluate whether a specific tool invocation is permissible given the current delegation, intent, resource sensitivity, and risk context. Those are authorization questions that require a separate policy decision at action time.
Investigators reconstructing an agentic incident need to answer questions that identity fields alone cannot address: who authorized the agent to act, what the stated intent was, whether the tool invocation was consistent with that intent, what policy was in effect and why it allowed or denied the action, and how the action connects to other events in the A2A and MCP session. An audit record that captures only agent identity and API call timestamps cannot establish whether the action was policy-valid or demonstrate compliance to an auditor. The recommended minimum includes agent and blueprint identifiers, human delegator identifier, intent or task identifier, tool name and method, resource classification, policy version and decision reason codes, and session correlation identifiers.
Every agent deployment that allows tool execution against real systems should have runtime authorization enforcement, even at small scale. The reason is not complexity — a simple deny-by-default policy with explicit allow rules for known safe tool categories is a valid starting point. The reason is that without a policy enforcement point, authorization defaults to whatever the agent's OAuth scopes permit combined with whatever logic is hardcoded in the tool servers, and neither of those is a runtime decision. As deployments grow and tool catalogs expand, the cost of adding authorization later is always higher than starting with a gateway that can be configured incrementally.
Co-Founder / CEO at Permit.io
