Identity assertion grants are changing MCP authorization for AI agents

At a glance

What this is: This is an analysis of how ID-JAG changes MCP authorization for AI agents by replacing repeated per-app OAuth prompts with IdP-backed identity assertion.

Why it matters: It matters because IAM teams can reduce approval friction without assuming authorization is complete, and they still need separate controls for agent actions, scope, and auditability.

Context

MCP-connected AI agents often need access to multiple enterprise apps in a single task, which exposes a gap in traditional OAuth flows. Those flows assume a human is present to approve each new connection, while agent-led work can span many tools without repeated user interaction.

The identity problem is not just authentication. It is whether an already authenticated user can be represented safely across downstream tools without creating a new standing trust path that exceeds the original consent and policy boundary.

Hush Security's article frames ID-JAG as a way to reuse enterprise identity trust for MCP authorization, not as a full governance model for agent behaviour after access is issued.

Key questions

Q: What breaks when AI agents have to click through OAuth consent for every MCP tool?

A: Repeated consent flows break down because agent-led work can span multiple apps in one task, while OAuth prompts assume a human is present to approve each step. The result is approval fatigue, inconsistent user experience, and pressure to adopt weaker workarounds such as shared credentials or static tokens. That weakens accountability and makes downstream access harder to govern.

Q: Why do identity assertion grants reduce friction without solving agent risk?

A: They reduce friction because the identity provider can vouch for an already authenticated user across connected apps, so the agent does not need a fresh approval for each tool. They do not solve risk because the grant only decides whether access can start. What the agent does after access is issued still needs separate policy, review, and logging.

Q: How should security teams govern managed MCP access for AI clients?

A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.

Q: What is the difference between agent permissions and action-level governance for AI tools?

A: Agent permissions answer whether a connector can be used at all, while action-level governance decides whether a specific proposed operation should proceed. A mailbox may allow sending, yet still block messages containing sensitive financial data or require approval for unfamiliar recipients. Teams need both layers because broad access and acceptable use are not the same control.

Technical breakdown

How ID-JAG brokers trust through the identity provider

Identity Assertion JWT Authorization Grant, or ID-JAG, is an OAuth extension that lets a tool request a short-lived assertion from the same identity provider already used for login. The identity provider vouches that the agent is acting for an authenticated user and scopes that assertion to a specific receiving app. The app still decides what to trust and what access to mint. This preserves enterprise SSO as the trust anchor while avoiding repeated user approval for every downstream tool connection. It is a grant-brokerage pattern, not a new identity system.

Practical implication: Treat ID-JAG as a connection-layer control and verify that each relying app enforces its own scope checks before issuing downstream tokens.

Why MCP authorization breaks when humans must approve every tool

MCP-connected tasks can span the wiki, chat, ticketing, calendar, and productivity apps in one session. Standard OAuth consent flows are built around a person stopping to click Allow for each new app, which is workable for occasional manual integration but collapses under agent-driven, multi-step work. The friction is not merely usability. It creates pressure to bypass authorization with shared credentials or static tokens, which weakens accountability and makes downstream access harder to trace back to a real user decision.

Practical implication: Map where repeated consent is pushing teams toward shared access patterns, then replace those paths with per-user, IdP-backed grants.

Why action-level governance still matters after authorization succeeds

ID-JAG answers whether an agent may reach a given app, but it does not govern what the agent does after the access token is issued. That post-grant phase is where prompt manipulation, excessive scope, or unsafe tool use can still produce harmful outcomes. For AI agents, the critical control boundary is not just who authenticated, but what actions are permitted, reviewed, and logged once the agent starts operating. Connection trust and action trust are different problems, and solving one does not solve the other.

Practical implication: Separate authorization to connect from authorization to act, and keep per-action policy outside the initial grant flow.

Threat narrative

Attacker objective: The objective is to get a trusted agent to perform an authorized-looking action that exceeds the user's real intent or the programme's governance boundary.

1. Entry occurs when an AI agent is legitimately connected to multiple MCP-backed tools through enterprise identity trust.
2. Escalation happens if the initial grant is broad enough that the agent can move from one approved tool to another without fresh action-level review.
3. Impact emerges when the agent is manipulated into carrying out an unsafe or out-of-scope action inside a trusted application path.

Breaches seen in the wild

• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.
• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

ID-JAG reduces consent friction, but it does not solve agent governance. The control changes how an already authenticated user is vouched for across MCP-connected apps, which is valuable in enterprise SSO environments. But the governance question moves immediately after the grant is issued: what actions can the agent take, under what scope, and with what audit trail? Practitioners should treat this as a connection-layer improvement, not as a complete authorisation model.

Action trust and connection trust are now separate identity problems. Traditional OAuth consent bundles them too tightly when agents need to reach multiple tools in one task. ID-JAG helps with trust propagation across apps, but the organisation still needs distinct controls for per-action approval, sensitive tool use, and delegated scope boundaries. The implication is that authorisation architecture must be split into connection issuance and runtime action governance.

Standing consent is the weak pattern that this protocol tries to avoid. Repeated OAuth prompts push teams toward static credentials, shared service accounts, or ad hoc workarounds that are harder to govern than the original problem. ID-JAG preserves user-specific trust while keeping the app in control of the final access decision. The practitioner lesson is to eliminate prompt fatigue without recreating standing access elsewhere.

Identity assertion is not a blank cheque, and the industry needs to say that clearly. The protocol vouches for the user context and the intended app, but it does not validate whether the downstream action is safe, appropriate, or reversible. That makes it a useful federation pattern for MCP, yet incomplete for agentic operations. Security programmes should align it with action-level policy, not confuse it with delegated autonomy.

Connection-layer identity for agents needs a named governance model. ID-JAG gives the category a more precise trust primitive for app-to-app access, but the broader market still lacks consistent language for where connection authorisation stops and runtime governance begins. That gap matters because tool connectivity will keep scaling faster than approval workflows. Practitioners should insist on models that separate authenticated continuity from permitted behaviour.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Identity assertion for MCP is a federation problem first. Enterprises will increasingly need to broker trust across apps without multiplying user prompts, but the control boundary remains the same: authenticated identity does not equal safe action. That means programmes should design for separate trust layers, one for connection and one for behaviour, rather than expecting a single OAuth-style grant to do both.

Action-boundary governance becomes the deciding maturity test. If an AI agent can inherit access cleanly but still trigger unsafe tool use, the programme has only solved usability, not governance. The next step is to make per-action policy and audit lineage part of the operating model, especially where MCP tools touch sensitive business workflows.

For practitioners

• Separate connection grants from action approvals Use ID-JAG or similar identity assertion flows only to establish that a specific authenticated user can reach a specific app. Keep tool invocation, data access, and high-risk actions governed by a second control layer that can approve or block behaviour after the session starts.
• Inventory where MCP flows still depend on repeated consent Identify every app connection that still forces users through per-tool OAuth prompts and track where teams are compensating with shared tokens, copied secrets, or informal exceptions. Those are the places where prompt fatigue is already eroding governance.
• Require app-side scope enforcement Verify that each receiving app independently validates the identity assertion and mints only the minimum downstream access needed for that app. The identity provider should vouch for context, but it should not become the sole policy engine for every connected service.
• Build audit trails around the acting user, not just the connector Log the authenticated user, the issuing identity provider, the target app, and the action that followed the grant so investigators can separate legitimate delegated access from unsafe agent behaviour. Without that lineage, MCP connectors become hard to review.

Key takeaways

• ID-JAG changes how agents inherit enterprise trust across MCP-connected tools, but it does not decide what those agents may do after access is issued.
• The main operational value is reducing repeated OAuth prompts, which should lower pressure to use shared credentials or static workarounds.
• Practitioners still need action-level policy, logging, and approval boundaries because the post-grant behaviour of an agent remains a separate governance problem.

Key terms

• Identity Assertion Authorization Grant: An OAuth extension that lets an identity provider issue a signed, short-lived assertion saying a specific client may act for a specific user at a specific downstream app. It shifts approval from the target tool to the enterprise identity plane, which is what makes cross-app delegation governable at scale.
• MCP authorization: MCP authorization is the control layer that decides whether an agent or client may use a specific tool in a specific context. In secure deployments, it must go beyond token claims and incorporate user identity, resource ownership, and policy at request time.
• Action-Level Governance: Action-Level Governance is the practice of controlling what an agent, user, or system can do at each discrete step of execution. It applies policy to individual actions, not just to the identity itself. In AI and automation, it limits tool use, data access, approvals, and side effects in real time.
• Identity Provider Brokered Trust: Identity provider brokered trust is a federation pattern in which the login authority also serves as the entity that vouches for downstream access claims. For agents, this can reduce repeated consent prompts, but it does not remove the need to validate scope, intent, or post-grant actions at the receiving app.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.