Cross app access for AI agents shifts authorization to the IdP

At a glance

What this is: This is an analysis of Cross App Access for AI agents, showing how IdP-mediated authorization replaces direct app-to-app trust and makes agent access governable at the identity layer.

Why it matters: It matters because IAM teams now need to govern agent-to-tool connections as first-class access paths, not as side effects of SSO or per-app OAuth consent.

Context

AI agents are increasingly acting across multiple enterprise systems in a single task, which exposes a governance gap in how those connections are authorised. When access is granted outside the identity perimeter, security teams lose a central view of who or what can act across tools, and they lose a clean revocation point.

Cross App Access addresses that gap by moving the authorisation decision into the identity provider rather than leaving it between the client and the resource app. In practical terms, that makes agent-to-tool access closer to normal IAM governance, but only if the gateway, IdP, and downstream apps all participate in the same control path.

Key questions

Q: What breaks when AI agents chain access across tools and services?

A: The original approval no longer describes the effective access path. Each individual hop may look legitimate, but the combined chain can extend privilege beyond what the organisation intended. The failure is visibility across the delegation chain, not just at the first credential issuance point.

Q: When should organisations prioritise IdP-mediated authorization over per-app consent?

A: They should prioritise it when agents chain across multiple systems, when downstream access must be revoked centrally, or when standing credentials would otherwise persist beyond the task. The more tools an agent can touch, the less defensible isolated consent becomes as a governance model.

Q: What are the signs that agent access is becoming ungovernable?

A: Look for shared secrets across tools, inherited CI identity, inconsistent credential use between runs, and logs that cannot explain which prompt led to which action. Those signals show that the agent’s access path is being assembled on the fly and can no longer be reviewed as a fixed workflow.

Q: How can security teams tell whether Cross App Access is actually improving control?

A: Look for a single policy and audit trail in the IdP that lists approved client-server pairs, granted scopes, expiry times, and revocation actions. If those decisions still live in downstream apps, the organisation has visibility but not governance.

Technical breakdown

How IdP-mediated token exchange changes agent authorisation

Cross App Access extends OAuth 2.0 so an identity provider can approve an application-to-application relationship before a downstream token is issued. Instead of the client and resource app establishing trust directly, the IdP evaluates policy, issues a signed assertion, and scopes access to a specific audience. That matters because the user identity is no longer enough; the enterprise must authorise the requesting app as a distinct principal. In MCP environments, this creates a cleaner separation between authentication, policy evaluation, and tool access. The gateway can then redeem short-lived tokens without exposing long-lived credentials to the agent.

Practical implication: Use the IdP as the policy decision point for agent-to-tool access rather than relying on per-app consent or embedded credentials.

Why static keys and per-user consent fail at agent scale

Static API keys create standing privilege because they persist beyond the task that needed them, and per-user OAuth consent fragments authorisation across every client, tool, and session. Both patterns make revocation hard and inventory incomplete. The article’s central point is that AI agents multiply this problem because they chain tools dynamically, so the old model of one app plus one user plus one grant stops matching reality. In an MCP gateway design, the problem is not the call itself but the unmanaged trust relationship that sits behind the call.

Practical implication: Eliminate persistent downstream credentials and replace user-by-user consent sprawl with centrally governed, short-lived access grants.

How an MCP gateway becomes the enforcement layer

An MCP gateway is the right place to terminate identity because it already sits between the requesting app and the resource app. That lets it validate inbound identity, apply RBAC or ABAC, exchange tokens with the IdP, and broker access to servers that do not speak Cross App Access natively. The architectural point is important: the gateway is not just a pass-through, it is the control plane that turns a distributed agent estate into a governable access surface. Without that layer, enterprises end up with many isolated trust decisions and little audit continuity.

Practical implication: Place agent access mediation at the gateway boundary so every tool call inherits the same identity policy and audit trail.

Threat narrative

Attacker objective: The objective is to gain persistent, hard-to-revoke access paths that let an agent or compromised client act across multiple enterprise systems without central oversight.

1. Entry occurs when an AI client or agent connects to enterprise tools using scattered OAuth consent, static keys, or other unmanaged app links.
2. Credential exposure or overbroad grant follows when those connections carry standing privilege across Jira, Slack, data warehouses, or internal systems.
3. Escalation happens as the agent chains multiple tools under one task while the IdP has no direct visibility into the full relationship.
4. Impact is unmanaged shadow AI: access cannot be inventoried cleanly, revoked centrally, or scoped consistently across downstream systems.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cross app access turns agent authorization into an identity governance problem, not a tool-integration problem. Once the IdP becomes the policy authority, the enterprise can finally answer which client may reach which tool on whose behalf. That changes the control objective from tracking integrations to governing delegated access. Practitioners should treat agent-to-tool relationships as access entitlements with lifecycle, audit, and revocation requirements.

Standing credentials are the wrong trust model for AI agents. The article makes clear that static keys and per-user consent both create blind spots because the enterprise cannot see or revoke the relationship in one place. That is not a minor implementation flaw, it is a structural mismatch between distributed agent execution and legacy access grants. The implication is that agent access must be short-lived, scoped, and centrally mediated.

Identity providers are becoming the control plane for autonomous work, and that widens the IAM boundary. When the gateway brokers token exchange and the IdP approves the connection, policy now spans authentication, authorisation, and downstream tool reach. This is where NHI governance and human IAM start converging: the same revocation and audit discipline must now cover users, agents, and the delegated paths between them. Security teams should re-map those trust edges before the number of hidden agent connections grows further.

Unified auditability is the real prize, not just convenience. The value of Cross App Access is that it converts opaque app links into grants that can be logged, reviewed, and revoked centrally. That matters because governance fails when the organisation can see users signing in but cannot see what their agents are allowed to do next. Practitioners should measure success by whether every agent-to-tool grant is attributable and disposable.

Shadow AI here is an access-control symptom, not a discovery problem alone. Discovery matters, but the deeper issue is that unmanaged agent connections become normalised when authorisation lives outside the IdP. A useful named concept here is authorization perimeter drift: the trust boundary moves into applications and gateways without the identity team owning it end to end. Teams should treat that drift as a governance defect, not a monitoring gap.

From our research library:

• The average worker in a typical enterprise holds 96,000 entitlements, and 38% of IdP accounts are dormant, according to Veza's 2026 State of Identity and Access Report.
• Read next: MCP Security Guide

What this signals

Authorization perimeter drift: AI agents expose a new class of access problem where the identity boundary no longer matches the execution boundary. When consent, token exchange, and revocation are split across apps, the organisation cannot prove who or what is authorised at any given moment.

The practical response is to move agent-to-tool trust into the same governance layer that already handles identity lifecycle and access review. That makes the gateway an enforcement point, but only if every downstream connection is accountable to the IdP and not just to the application owner.

For practitioners

• Define the agent authorization boundary Map every place an AI client, MCP gateway, or downstream tool establishes trust outside the IdP, then classify those paths as governed access relationships.
• Replace standing downstream credentials Remove long-lived API keys and shared secrets from agent workflows where the gateway can broker short-lived, audience-scoped tokens instead.
• Centralize offboarding for agent-linked access Tie agent and user deprovisioning to the same identity lifecycle so revocation reaches tool access, not just login access.
• Log each tool grant and token exchange Capture which agent, user, target server, and scope were involved in every brokered request so reviewers can trace authorization decisions later.

Key takeaways

• Agentic access becomes a governance issue once the IdP is no longer the place where tool relationships are authorised and revoked.
• Static keys and scattered consent create standing privilege for AI workflows, which expands the blast radius of any compromised or misconfigured agent.
• Centralised token exchange, short-lived scope, and complete audit trails are the controls that make agent access reviewable at enterprise scale.

Key terms

• Cross App Access: An ecosystem name for IdP-mediated app-to-app authorization in enterprise environments. It allows an identity provider to approve or deny AI app connections centrally, reducing hidden delegation and making downstream access revocable from one place instead of inside every connected tool.
• 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.
• Authorization Perimeter Drift: Authorization perimeter drift is the condition where access decisions move out of the identity provider and into scattered applications, gateways, or local secrets. For AI agents, that drift makes tool access hard to inventory, hard to revoke, and easy to leave standing long after the original task ends.
• Agent-to-Tool Trust: Agent-to-tool trust is the delegated relationship that allows an AI client or gateway to reach a downstream system on behalf of a user or team. In an enterprise setting, it must be treated as a governed entitlement, because the trust relationship can span multiple apps, scopes, and identities at once.

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.