> ## Documentation Index
> Fetch the complete documentation index at: https://www.truefoundry.com/llms.txt
> Use this file to discover all available pages before exploring further.

# TrueFoundry as the Identity Broker

> Governing agents when TrueFoundry issues agent identities and brokers all access — no agent-capable identity provider required.

Use this scenario when your identity provider has no agent-identity capability (or you don't want to depend on one yet), and you want the fastest path to governed agents. TrueFoundry plays all three control-plane roles for agents: it **issues** each agent's identity, **authorizes** every call, and — with token exchange — **mints** the scoped credential for each hop. Your enterprise IdP keeps doing what it already does: authenticating human users.

<Note>
  This is the default scenario. Every other scenario ([Okta](/docs/agent-platform/agent-governance/scenarios/okta), [Entra](/docs/agent-platform/agent-governance/scenarios/microsoft-entra), [SPIFFE](/docs/agent-platform/agent-governance/scenarios/spiffe)) changes only *where the agent's identity comes from* — the gateway checks and the governance model stay identical, and you can mix scenarios per agent in one tenant.
</Note>

## How the pieces map

| Blueprint role                     | Played by                                                                                                                                     |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| Identity provider (users)          | Your existing IdP / SSO — users resolve to TrueFoundry users via [Identity Providers](/docs/platform/identity-providers) or a TrueFoundry PAT |
| Identity provider (agents)         | **TrueFoundry** — a signed token minted per registered agent                                                                                  |
| Authorization                      | The Agent Gateway and MCP Gateway, from collaborator grants                                                                                   |
| Token issuance per hop             | **TrueFoundry as STS** — gateway-issued scoped tokens *(coming soon)*                                                                         |
| Credentials to third-party targets | The MCP Gateway's outbound auth: managed credentials, client credentials, or per-user OAuth                                                   |

## The flow

Registration creates the identity; the agent fetches its token (**⋮ → Get Token** in the registry) and presents it alongside the user's token on every call.

```mermaid theme={"dark"}
sequenceDiagram
    participant Jane as Jane (user)
    participant Agent as research-agent
    participant GW as TrueFoundry Gateway
    participant MCP as Jira MCP Server

    Note over Agent: Holds a TrueFoundry-signed agent token
    Jane->>Agent: "Summarize my open issues"
    Agent->>GW: Authorization: Jane<br/>x-tfy-agent-authorization: research-agent
    GW->>GW: Validate both tokens (TrueFoundry-signed)
    GW->>GW: research-agent allowed on Jira MCP?<br/>may act for Jane?
    GW->>MCP: Forward with outbound auth for Jira
    MCP-->>GW: Jane's issues
    GW-->>Agent: Result
    Agent-->>Jane: Summary
```

Because TrueFoundry signs and validates both credentials itself, there is no external token exchange to configure — the gateway *is* the trust domain. Authorization comes entirely from grants you manage in one place:

* the agent's **collaborators** decide who may invoke it and whom it may act for;
* the agent's presence as a **collaborator on each target** decides what it may reach;
* everything else is denied with a `403`.

## Reaching targets that need their own credentials

The agent's TrueFoundry identity gets it *through the gateway*; the target may still need an upstream credential. The MCP Gateway's [outbound authentication](/docs/ai-gateway/mcp/mcp-gateway-auth-security#outbound-authentication) handles this per server, and the agent never holds any of these credentials:

| Target                                      | Outbound auth to use                                                                                             |
| ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| Internal MCP server that trusts the gateway | No auth, or a TrueFoundry-managed header credential                                                              |
| SaaS API with app-to-app support            | OAuth2 **client credentials**, held centrally by the gateway                                                     |
| SaaS API that requires per-user consent     | OAuth2 **authorization code** — the gateway runs 3-legged OAuth per user, stores and refreshes each user's token |

<Warning>
  An agent calling on its own (no user in the loop) cannot complete an authorization-code flow — there is no human to approve the consent screen. For those targets, use client credentials where the provider supports it. See [which MCP server auth types an agent can use](/docs/agent-platform/agent-governance/agent-registry#which-mcp-server-auth-types-an-agent-can-use).
</Warning>

## Coming soon: the gateway as STS

Today the user's token passes through alongside the agent header. In the target model, the gateway acts as the **Security Token Service** for its own domain: at each hop it mints a short-lived TrueFoundry-signed token with the user as `sub`, the acting agents nested in `act`, and audience and scope narrowed to exactly the next callee — bringing full [per-hop exchange semantics](/docs/agent-platform/agent-governance/governance-blueprint#4-authorize-and-scope-the-per-hop-loop) without any external identity provider in the path. Downstream MCP servers you control validate a single issuer (TrueFoundry) and get delegation, attribution, and least privilege in one signed object.

## When to choose this scenario — and when not to

**Choose it when:**

* your agents are built and run in-house, and targets are internal or reachable with gateway-held credentials;
* you want governance running this week, with the option to move individual agents to IdP-backed identities later (each agent chooses independently);
* your IdP has no agent support, or its agent products aren't licensed or enabled yet.

**Prefer an IdP-backed scenario when:**

* your security organization requires every principal — human and non-human — to live in the corporate directory;
* you need IdP-brokered access into *other* trust domains (Cross App Access to third-party SaaS), which only the enterprise IdP can broker — see [Okta](/docs/agent-platform/agent-governance/scenarios/okta);
* agents already have identities in Entra or Okta that other systems rely on — see [Microsoft Entra](/docs/agent-platform/agent-governance/scenarios/microsoft-entra).