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:

‍