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:

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:

One caveat worth stating up front: an agent acting without a user cannot complete an authorization-code flow, because there is no human to approve the consent screen. For unattended agents, use a mode that does not need per-user consent. The outbound token model is the one we detail in OAuth and enterprise token management for MCP.

Where teams get this wrong

Thinking the broker is all-or-nothing. The other scenarios (Okta, Entra, SPIFFE) change only where the agent's identity comes from. You can mix scenarios per agent in one tenant, and the gateway checks stay identical.

Using an unattended agent with an authorization-code target. No human means no consent screen. Choose client-credentials or a managed credential for agents that run on their own.

Confusing reaching a target with acting for a user. They are separate grants. An agent that is a collaborator on a server still needs permission to act for the specific user it claims to represent — see fine-grained authorization.

Skipping the migration plan. The broker is the fast path, but if policy will eventually require all principals in the corporate directory, register agents in a way that makes the later move to Entra or Okta a config change, not a rebuild.

Want governed agents without waiting on an IdP migration?

Start free on TrueFoundry

When to choose the broker — and when not to

Choose the broker scenario when your agents are in-house and their targets are internal or reachable with gateway-held credentials; when you want governance running quickly; or when your IdP lacks agent support. Prefer an IdP-backed scenario when security policy requires every principal to live in the corporate directory, when you need IdP-brokered access to third-party SaaS (for example Okta Cross App Access, covered in TrueFoundry and Okta Cross App Access), or when agents already have Entra or Okta identities that other systems depend on.

A worked example

A team wants a research-agent to read Jira on behalf of users, but their IdP has no agent product enabled. They register the agent in TrueFoundry (broker scenario), grant the research team Agent Access so the agent may act for them, and add the agent as a collaborator on the Jira MCP server with a gateway-held credential. The agent pulls its token, sends it with each user's token, and the gateway authorizes the pair and forwards the call. Months later, when the org standardises on Entra Agent ID, they flip that one agent to identity-provider-backed — the collaborator grants and audit trail carry over unchanged.

Gotchas worth knowing

• Per-hop STS issuance is marked coming soon. The planned model mints a short-lived, TrueFoundry-signed token at each hop with the user as sub and acting agents in act, narrowing audience and scope to the next callee.
• Keep the agent token out of model-readable context. A prompted agent that can disclose its token can be impersonated.
• Denied calls return `403`, naming the refused principal and reason — useful when a grant is missing on one of the two axes.
• Per-user OAuth means the gateway stores and refreshes tokens; plan for that state and its encryption.
• One tenant can mix scenarios. You do not have to pick broker or IdP for the whole estate — decide per agent.

The planned STS model, and why it matters

Today the broker signs one agent token per registered agent and checks it on every call. The piece marked coming soon in the docs is the gateway acting as a full security token service (STS) that mints a fresh, short-lived token at each hop of a chain. In that model the user stays as sub, every acting agent is recorded in a nested act claim, and the audience and scope narrow to the next callee — so a token minted for the research agent to call Jira cannot be replayed against Confluence. The payoff for a downstream MCP server is simplicity: it validates a single issuer (the gateway) rather than learning to trust every agent and IdP in your estate. If you are designing multi-agent chains now, build against the two-header model and treat per-hop STS as a drop-in hardening you adopt when it lands, not a rebuild.

Choosing a scenario

The broker is one of four identity scenarios, and the only thing that changes between them is where the agent's identity comes from. The gateway's authorization checks, collaborator grants, and audit are identical, which is what lets you mix them per agent in a single tenant.

The practical pattern most teams land on: start every agent on the broker to get governed quickly, then migrate the handful that policy or integrations require into an IdP-backed scenario. Because the grants and audit carry over, that migration is a configuration change on one agent, not a project. The IdP-backed options are covered in TrueFoundry and Okta Cross App Access and the Entra and SPIFFE guides.

Outbound auth, decided per target

The inbound side (who the agent is, whom it acts for) is uniform; the outbound side (how the gateway authenticates to the tool) is chosen per target, and getting it wrong is the most common reason an otherwise-governed agent cannot actually reach a system. A quick decision guide: if the target is an internal MCP server that trusts the gateway, use no auth or a managed header credential; if it is a SaaS API that supports app-to-app access, use OAuth2 client credentials held centrally by the gateway; if it is a SaaS API that requires per-user consent, use the OAuth2 authorization-code flow, where the gateway runs per-user OAuth and stores and refreshes each user's token. The one hard constraint: an unattended agent — one acting with no user — cannot complete an authorization-code flow, because there is no human to approve the consent screen. Give such agents a client-credentials or managed-credential target instead, and plan encrypted storage for the per-user tokens the gateway holds, as covered in OAuth and enterprise token management for MCP.

Related reading

• Agent Identity and On-Behalf-Of Delegation — the two-header model in detail
• What Is AI Agent Identity? — the concept the broker delivers
• TrueFoundry and Okta Cross App Access — the IdP-backed alternative
• OAuth and Enterprise Token Management for MCP — outbound credentials to third-party tools
• What Is MCP Authorization? — the grants behind every call

Conclusion

The identity-broker pattern exists because agents arrive faster than agent-aware IAM. Rather than wait, you let one trusted component issue agent identity, authorize every call, and broker credentials to each target — with your human IdP untouched. TrueFoundry plays that broker: it signs and validates both the user and agent tokens, governs the call from grants in one place, and keeps the door open to federate with Entra, Okta, or SPIFFE whenever you are ready.

It is the shortest path from agents running loose to agents under governance — without betting the estate on a single identity vendor.

Broker your agents' identity in one place.

Book a demo