Introducing Agent Identity: verifiable identity for every AI agent. Updated: October 29, 2026 Published: October 29, 2026 TrueFoundry is 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 TrueFoundry is launching Agent Identity in TrueFoundry's Agent Gateway. Why TrueFoundry built Agent Identity. TrueFoundry 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. TrueFoundry 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? Try now. One gateway for all your models, MCP servers, and agents. No credit card needed. Table of Contents One gateway for every LLM, agent and MCP server. Book a 30-min with its AI expert Summarize with Frequently asked questions. What is agent identity? How is on-behalf-of different from token pass-through? Does Agent Identity work with Okta and Microsoft Entra? Can I deploy TrueFoundry in my own VPC or on-prem? Does TrueFoundry support MCP and AI agents?

TrueFoundry ships Enterprise MCP Gateway: tool discovery governance as the next battleground. TrueFoundry's Enterprise MCP Gateway turns agent tool access into a governed decision, and marks where value in agent infrastructure is moving: from the runtime to the control plane. Blair Hayes Forkast mind | 2026-10-14 5:58 AM PDT Every agent that connects directly to every tool has to solve the same four problems on its own: authentication, authorization, routing, and error handling. Multiply the number of agents by the number of tools and the result is the NxM integration matrix, a sprawl of point-to-point connections that no security team can inventory and no platform team can maintain. On Oct. 12, TrueFoundry shipped its answer: the Enterprise MCP Gateway announcement describes a control plane that sits between agents and their tools and decides who may call what. The runtime layer of agent infrastructure is commoditizing. The layer that governs access is where the moat is moving. The gateway itself is deliberately unglamorous: a reverse proxy between AI agents on one side and MCP servers on the other. Its value is concentration. A centralized MCP registry keeps every approved server and its authentication mechanism in one place; users authenticate once to the gateway, and the gateway stores, refreshes, and injects the downstream credentials. For a platform team, that turns credential sprawl - API keys and OAuth tokens scattered across agent codebases - into a single rotation point. It is plumbing, in the plainest sense - which is exactly where control tends to consolidate. The most consequential feature is the Virtual MCP Server. Instead of exposing a full tool surface, a team can compose a curated endpoint from safe subsets of several backends - query access from a data warehouse, a rate lookup from a payments provider, an alert from a chat tool - while leaving destructive operations like project deletion off the list entirely. The agent sees one endpoint; the gateway routes underneath. Least-privilege access expressed as product design: the unit of governance is no longer the credential, it is the tool list. Identity is the other half. The companion post describes OAuth 2.0 identity injection: when a user asks an agent to create a ticket, the gateway intercepts the call and injects that user's own token, so the agent acts on the user's behalf and can only touch what the user can touch - "no shared keys." Underneath sits a four-layer stack: gateway authentication via API key or the customer's own identity-provider token, group-level access control with named managers, per-server authorization (none, static headers, or OAuth2), and a custom-header override. TrueFoundry's Okta OAuth walkthrough shows the machinery end to end, on-behalf-of token exchange included. Human identity and service identity stay separated at the boundary instead of being blended into one privileged agent role.