AI
The 4-Legged Identity Challenge
The three-legged OAuth flow (user, application, API) works because the application is deterministic. It executes the user’s intent directly. Once an agent and an MCP server sit between the user and the API, that assumption breaks. The agent decides which tools to call dynamically. The MCP server executes the call. The downstream API can no longer identify who is acting. Tokens are audience-bound. A token issued for one service cannot be reused for another. The result is identity loss midchain, the core of the four-legged challenge.
Four RFCs, One Life Cycle
Agent-to-MCP communication needs four standards working together. RFC 9728 lets the resource tell the agent which authorization server it trusts and what scopes it requires. RFC 8414 publishes the authorization server’s endpoints, token endpoint, and signing key location. RFC 7591 lets the agent register itself programmatically instead of requiring a human admin to pre-wire every connection. RFC 8693 enables token exchange, trading a user’s token for a new one scoped to a different audience. These four form a single lifecycle: discover, authenticate, register, delegate.
Enterprise Security Layers
Identity alone is not enough. Every MCP server should revalidate tokens instead of trusting upstream systems blindly. Tokens must be short-lived and scoped per hop. Envelope encryption keeps data encryption keys transient while key encryption keys live in a vault. Every tool invocation needs full audit context, including who initiated it, which agent executed it, which tool was called, and the outcome. Data loss prevention scanning should catch PII or secrets in outbound responses. PKI and mTLS ensure internal communication is always verified.
Token Exchange and Broker Patterns
Two labs demonstrate the concepts. The first shows a user logging in through a web app, obtaining a token, and exchanging it for a new token valid for a downstream resource. The audience field changes while the user identity is preserved. The second lab introduces a broker layer that centralizes token exchange, caching, and secret management. The broker sits between the application, MCP servers, and downstream APIs. It integrates with Keycloak for identity and OpenBao for secrets. This broker pattern becomes necessary when systems scale beyond a few services.
Q&A
What common practices are emerging for carrying identity across token boundaries? The audience is the biggest change because tokens are audience-bound and must be exchanged for each new server. ▶ Watch (23:52)
How does revocation work for token delegation? A centralized broker layer can revoke tokens instantly across the entire chain. ▶ Watch (24:48)
What standards exist for agent-to-agent communication? No great standards have emerged yet, but agents should be treated as protected resources with the same security measures applied to every call between them. ▶ Watch (25:35)
Notable Quotes
four legs is actually just the minimum viable complexity Paulina Xu · ▶ Watch (0:28)
standard OOTH is not broken, but it is incomplete Paulina Xu · ▶ Watch (21:21)
Identity is now becoming a process, not just a token. Paulina Xu · ▶ Watch (15:48)
Key Takeaways
- OAuth’s three-legged model fails when agents dynamically discover and call MCP servers across multiple hops.
- Four RFCs (9728, 8414, 7591, 8693) form a complete lifecycle for dynamic delegation.
- Security requires layered enforcement of least privilege, encryption, observability, and secret management.
About the Speaker(s)
Paulina Xu is the CEO of Agentic Fabriq, where she is building a centralized hub for agent identity, OAuth-based authentication, permissioning, and auditability, enabling organizations to safely manage what agents can access and do across tools, applications, and teams. Prior to founding…