November 1, 2026
|
5 min read
The Identity-Broker Pattern for AI Agents: One Trust Boundary for Every Credential
.png)
Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
The problem: agents arrive before agent-aware IAM
Enterprise IAM was built for humans and service accounts. Agents are neither: they act for a user, across several tools, often in chains. If your identity provider has no agent-identity capability — or you simply don't want to depend on one yet — you are left with the three bad options every agent deployment starts with: borrow the user's token, share a service account, or impersonate. All three break the audit trail, as we cover in what AI agent identity is.
The identity-broker pattern lets you skip the wait. One trusted component becomes the issuer and authority for agent identity, so you get governed agents today and keep the option to federate with your IdP later.
What the broker actually does
A broker takes on three roles that would otherwise be spread across your IdP, your app code, and each tool. With TrueFoundry as the broker, they map like this:
How a call flows
Registration creates the agent's identity. The agent gets its token from the registry (via ⋮ → Get Token) and sends it with the user's token on every call:
Registering an agent. The broker scenario uses a TrueFoundry-backed identity; you can switch an agent to an IdP later. Source: TrueFoundry docs.
Authorization: Bearer <USER_TOKEN>
x-tfy-agent-authorization: Bearer <AGENT_TOKEN>
The gateway validates both tokens, checks whether the agent may reach the target MCP server and whether it may act for the user, then forwards the request using the target's outbound auth. Anything not granted is denied with a 403. Because TrueFoundry signs and validates both credentials, the gateway is the single trust domain — there is no external exchange to stand up.
Reaching third-party targets
The broker also solves outbound credentials, which is where most agent integrations actually stall. It offers three outbound modes depending on what the target supports:
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
Built for Speed: ~10ms Latency, Even Under Load
Try now.
Start free
How Can You Prevent GenAI Costs From Spiraling at Scale?
Gartner Hype Cycle for Platform Engineering 2026
One Layer of Control for All AI
Discover More
No items found.
.png)
.png)
.png)
No items found.
Recent Blogs
.png)
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
Frequently asked questions
What is an identity broker for AI agents?
A component that takes on the agent control-plane roles your IdP and app code otherwise would: issuing each agent's identity, authorizing every call, and minting scoped credentials for each hop. In TrueFoundry the gateway is the broker, and it signs and validates the agent token itself.
When should I use the broker instead of my IdP?
When your IdP has no agent-identity capability, when you want governed agents quickly, or when your agents are in-house and their targets are internal or reachable with gateway-held credentials. If policy requires every principal in the corporate directory, use an IdP-backed scenario instead.
Does the broker replace my SSO?
No. Your enterprise IdP still authenticates human users. The broker only provides and governs agent identity, carrying the user's token alongside the agent's on every call.
How does the gateway reach third-party tools?
Through outbound auth on the MCP server: no auth or a managed header for internal targets, OAuth2 client credentials for app-to-app SaaS, or per-user OAuth (authorization code) when the SaaS needs per-user consent. The gateway stores and refreshes per-user tokens.
Can I move an agent to Okta or Entra later?
Yes. Only the source of the agent's identity changes; the collaborator grants, authorization checks, and audit trail stay the same. You can mix broker-backed and IdP-backed agents in one tenant.
What happens on an unauthorized call?
The gateway denies it with a 403 that names the refused principal and the reason — whether the agent lacked access to the target or lacked permission to act for that user.
