Skip to main content
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.
This is the default scenario. Every other scenario (Okta, Entra, 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.

​
How the pieces map

​
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. 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 handles this per server, and the agent never holds any of these credentials:
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.

​
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 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;
  • agents already have identities in Entra or Okta that other systems rely on — see Microsoft Entra.