Introducing Agent Identity: Verifiable Identity for Every AI Agent

We're releasing three major product updates to strengthen agent governance on TrueFoundry, giving teams control over which agents run, what they can reach, and on whose behalf they act.

Agent Identity is the first major launch in this series.

In a hospital, every doctor and nurse carries an ID badge. They tap it on the medication cabinet before they can dispense a drug, and the cabinet logs who took what, for which patient, and when. Now imagine a busy ward where a few people share one badge to save time. The log still says "Dr. Smith dispensed 10 mg of morphine at 2:14 a.m.", but nobody can say who actually opened the drawer. The record of the last credential used exists, but there’s no traceability beyond that.  

That is how most AI agents work today. Agents call models, MCP servers, and other agents using shared API keys, static service accounts, or whatever credentials the developer had at hand. When an agent issues a refund or updates a customer record, the logs show a key, not an agent, and not the person the agent was acting for. This was an inconvenience when agents operated at a small scale, mostly on internal workflows. But as the size of each enterprise’s agent fleet increases and teams begin deploying multi-agent systems that can touch sensitive records and take destructive actions, untraceability becomes a huge compliance and security risk. 

That’s why we're launching Agent Identity in TrueFoundry's Agent Gateway. 

Why we built Agent Identity

We kept hearing the same story from platform and security teams. Take a support portal: a support engineer, acting for a customer, asks the portal to process a payment. The portal calls a support orchestrator agent. The orchestrator hands the task to a payments agent. The payments agent calls a payments MCP server that actually writes the record.

Four hops later, the MCP server has to decide whether to act. Is this request coming from the portal? From the engineer? From the customer the engineer is helping? In most setups, it only sees the last agent in the chain, so it either trusts everything or trusts nothing.

Teams that tried to fix this ran into three problems:

• No identity per agent. Shared keys make it impossible to tell agents apart or revoke one without breaking others.
• User context lost between hops. Each agent re-authenticates as itself, so the person behind the request disappears.
• Auth rebuilt in every agent. Token exchange, refresh, and signing logic gets copied into each codebase, slightly differently each time.

Agent Identity moves all of this out of agent code and into the gateway.

Give every agent a verifiable identity, wherever it runs

Every agent registered in TrueFoundry's AI agent registry gets exactly one identity. You choose who backs it:

• TrueFoundry-backed: TrueFoundry issues and signs the agent's token. This is the easiest and fastest way to start as there’s no additional configuration needed.
• Identity provider–backed: The agent uses tokens from the identity provider you already run, such as Okta, Microsoft Entra, any OIDC provider, or SPIFFE/SPIRE. TrueFoundry maps the agent to a subject claim in the token, so your IdP stays the source of truth.

Agents don't need to move to get an identity. You can register agents running on AWS Bedrock AgentCore, Vertex AI, LangGraph, custom HTTP services, A2A agents, or TrueForge without rewriting them. Agents you route through the gateway get full policy enforcement on inbound calls. Embedded agents that can't be proxied still get an identity, and their outbound calls to models and MCP servers are still governed.

Control how identity flows across every hop

Authentication answers "who are you?" In a multi-agent chain, however, the harder question is "on whose behalf are you acting?" Agent Identity lets you decide, for each hop, how identity is presented to the next system:

• Token pass-through: The gateway forwards the caller's token unchanged. This can be used when the downstream system already trusts the original token.
• OAuth2 client credentials: The agent calls downstream as itself no matter who called it. This works like a shared service account, but scoped to one registered agent.
• On-behalf-of (OBO) token exchange: The gateway exchanges the caller's token with your IdP for a new token that carries both identities: this agent, acting for this user. We support Microsoft Entra (JWT bearer) and Okta (RFC 8693 token exchange).
• AWS SigV4: The gateway signs requests with AWS credentials for agents running in AWS.

How does this work in real life? Let’s go back to the support agent scenario from earlier. You might pass the token straight through between the orchestrator and the payments agent, then use on-behalf-of on the final call to the payments MCP. The MCP server now sees that the payments agent is acting for the support engineer, and can apply that person's permissions. In practice, the system of record at the end of the chain usually decides which identity it needs, and Agent Identity lets you meet that requirement without touching agent code. The gateway runs the exchange, caches and refreshes tokens, and rejects calls that don't carry the identity the next hop requires.

Govern who can call each agent and what it can call

Identity is only useful if you can act on it. Every agent has two sets of controls:

• Who can call this agent: An allow-list of users, teams, apps, and other agents with access to invoke it.
• What this agent can call: Permissions on the models, MCP servers, and other agents it's allowed to reach.

Agents can have an owner team and collaborators with Agent Manager or Agent Access roles. Access is allow-list based: remove a grant, and the gateway returns a 403 on the next call. These policies use the same RBAC model as every other TrueFoundry resource, so there's no separate permission system to learn.

Getting started with Agent Identity

Registering an agent takes four steps in the Agent Registry: Metadata, Agent Identity, Config, and Access Control. You can also apply the same configuration as YAML. Head to the Agent Registry documentation for a full walkthrough, including setup guides for Okta and Microsoft Entra.

Like to learn more about how Agent Identity in the TrueFoundry AI Gateway would work in your current set up?

Schedule your Demo Now →