Beyond the Consent Screen: Agent-to-Agent and Agent-to-App Trust
Part of the series The Authentication and Authorization Challenges of Agentic AI.
The previous two posts in this series dealt with delegation and consent within a boundary you largely control — your own APIs, your own users, your own approval flows. This one deals with what happens the moment an agent needs to reach outside that boundary: into another SaaS application, or into another organization’s agent entirely. That’s the trust-chain gap, and it’s the one that scales the worst if you try to solve it with the tools built for a single application.
Why per-application consent doesn’t survive contact with agents
The standard OAuth consent screen — “App X would like to access your Google Calendar, click to allow” — works because a human is present, deciding once, about one specific connection. It was designed for a world where a person connects a handful of apps to a handful of services over the life of an account. It was not designed for a world where an agent, acting on behalf of an enterprise, might need to reach into dozens of internal and partner systems, potentially adding new ones as its capabilities expand, with an IT or security team that has no visibility into which connections exist, who approved them, or under what policy.
Two failure modes show up quickly once you try to force agent access through this model. The first is consent fatigue at scale: employees click “allow” on prompts they don’t fully evaluate, because there are too many of them, which defeats the purpose of a consent step existing at all. The second, more consequential one: individual employees end up with the practical authority to connect an enterprise agent to whatever third-party service they want, one click at a time, entirely outside whatever access policy the organization actually intends to enforce. That’s shadow IT, reborn for agents, and it’s considerably harder to detect than the browser-extension version of the same problem, because the “installation” is often just an agent’s normal operation deciding to reach a new tool.
The pattern: let the identity provider mediate, the way it already does for SSO
The structural fix mirrors something enterprises already trust for a different problem: single sign-on. When an employee logs into a dozen different applications through one identity provider, none of those applications individually decide to trust the employee — they trust the IdP’s assertion that the employee is who they say they are, and the IdP enforces whatever policy governs which employees can reach which applications in the first place.
The extension being standardized for agent-to-agent and agent-to-app access does the same thing one layer up: instead of two applications establishing bilateral trust directly (the traditional OAuth consent model), the enterprise identity provider mediates the connection. Mechanically: after the employee authenticates via SSO, the requesting application (the agent, or the app hosting it) exchanges its existing identity token for a signed, cross-domain identity assertion from the IdP — contingent on whatever access policy the organization’s administrators have configured for that specific app-to-app connection. That assertion is then redeemed at the resource application’s own authorization server for a scoped, audience-bound access token, which the resource app can validate using the same trust relationship it already has with the IdP for ordinary SSO.
The result is structurally different from a user clicking “allow” on a consent screen: the IdP — not the individual employee, and not a bilateral agreement between two app vendors — is the party deciding whether this connection is permitted at all, based on centrally configured policy. If a connection was never supposed to exist, it doesn’t matter how many times an employee tries to authorize it; the IdP simply won’t issue the assertion.
This builds directly on the previous post’s token exchange (RFC 8693) and JWT bearer assertion (RFC 7523) mechanics, extended across a security-domain boundary rather than staying within one organization’s own APIs. The distinction matters: ordinary token exchange assumes you’re re-scoping access within a boundary you control end to end. This pattern assumes the requesting app and the resource app belong to different organizations or vendors entirely, and formalizes the IdP as the arbiter between them.
Where this stands, honestly
This is worth stating plainly rather than glossing over: the specification behind this pattern — the identity assertion grant that extends SSO trust to cross-domain API access — is, as of this writing, an active IETF draft, not a ratified RFC. Momentum behind it has accelerated specifically because of agentic use cases (an agent needing to reach a partner’s API on a user’s behalf is a much more urgent version of a problem that’s existed for SaaS-to-SaaS integration for years), and multiple identity vendors are already implementing against the current draft. That’s a reasonable bet, not a settled fact — expect the details to shift somewhat before final standardization, and treat any specific implementation you evaluate today as tracking a moving target.
Where this fits alongside everything else in the series
It’s worth being precise about what this pattern is for, because it’s easy to reach for it in the wrong situation. It solves the problem of governed, no-standing-consent access between applications that belong to different trust domains — an internal agent reaching a partner’s API, or an enterprise-managed agent reaching a SaaS tool the IT department has approved but doesn’t want every employee individually consenting to. It is not a replacement for the token exchange pattern from the previous post, which still governs delegation within a boundary you control; and it doesn’t remove the need for the asynchronous, human-approved consent from the post before that, for actions specific and sensitive enough to warrant a person’s explicit sign-off regardless of which application is involved.
In a multi-agent architecture, this gap compounds: agent A might need to reach agent B, which is itself hosted by a different team or a different organization entirely, and which then needs to reach a resource on the original user’s behalf. Each of those hops is a place where “does this connection exist because policy allows it” needs a real answer — not “because someone, at some point, clicked allow.”
Design guidance
Centralize the decision of which apps and agents can reach which other apps and agents. This is a policy question for whoever administers your identity provider, not a decision that should be delegable to individual employees one consent click at a time. If your organization can’t currently produce a list of which agent-to-app connections are permitted, that’s the gap to close before adopting this pattern, not after.
Keep assertions short-lived and audience-bound. A cross-domain identity assertion should be scoped tightly to the specific resource application it’s meant for, and should not outlive the specific need for it — the same short-lived, narrowly-scoped philosophy from the token exchange post, just operating across an organizational boundary instead of within one.
Don’t treat this as eliminating user consent — it relocates where the decision is made. An employee may still need to be the one who initiates a specific connection or approves an agent’s access to their own account within an app. What changes is that the ongoing authority for whether that connection is allowed to exist at all sits with enterprise policy, not with whatever the employee happened to click through.
Track draft status as a first-class risk, not a footnote. If you’re building against this pattern today, you’re building against a specification that’s still moving. Isolate that dependency so that when the draft’s details shift, the blast radius of updating your implementation is contained — not spread across every agent integration you’ve shipped.
Next in the series: Securing the New Attack Surface: Authorization for Tool-Calling Agents and MCP, which turns from which applications an agent is allowed to reach toward what a tool actually is, from an authorization perspective, the moment you hand one to an agent.