AI Product NewsAgent Identity

TrueFoundry’s Agent Identity: Why Agents Need Verifiable, On‑Behalf‑Of Identities

TrueFoundry’s Agent Identity gives every autonomous agent a verifiable credential and configurable identity flow. This changes how enterprises enforce least privilege, preserve user context across multi‑agent chains, and create audit trails that attribute actions to a specific agent and end user — not a shared API key.

NexusAI Editorial DeskOct 30, 20262.0K views6 min read

TrueFoundry’s Agent Identity: Why Agents Need Verifiable, On‑Behalf‑Of Identities

AI Brief

Agent Identity resolves a persistent governance gap: agents today act using shared or static credentials, erasing traceability and forcing downstream systems to guess which human or agent initiated an action. TrueFoundry’s design gives every registered agent a verifiable token (TrueFoundry-backed or IdP-backed), configurable pass‑through, OBO exchange, or SigV4 signing, and allow‑list based policies for who an agent can call and what it may reach. For platform teams this reduces blast radius, restores user context across hops, and centralizes token exchange and policy enforcement at the gateway, cutting duplicated auth code and improving auditability.

Most production agents still operate with blunt instruments: shared API keys, service accounts, or embedded credentials. That works for small fleets running non‑critical tasks, but it collapses under multi‑agent orchestration that touches payments, patient records, or privileged infrastructure. When a downstream MCP server or database sees a request authenticated by a key, it can’t determine which agent or human intended the action, so teams either over‑trust or lock everything down and break workflows.

TrueFoundry’s Agent Identity reframes the problem: each agent is a principal with a verifiable credential, issued by TrueFoundry or backed by your IdP (Okta, Microsoft Entra, OIDC, SPIFFE). That identity is independent of runtime and hosting, so agents on Bedrock AgentCore, Vertex AI, LangGraph, or custom services can be governed without code changes. The gateway handles token lifecycle, caching, and exchanges — eliminating bespoke token plumbing in every agent implementation.

Critically, Agent Identity doesn’t just name the agent — it models who the agent is acting for. Gateway options include token pass‑through, OAuth2 client credentials (agent as itself), and on‑behalf‑of (OBO) token exchange which binds agent and user context into a downstream token. That lets the system of record apply per‑user permissions at the final hop without trusting intermediary code or duplicating auth logic in every agent.

For platform and security teams, the benefits are practical and immediate: precise allow‑lists (who can call an agent), scoped egress permissions (what models, MCP servers, or tools an agent may invoke), revocation without collateral damage, and end‑to‑end audit trails that attribute actions to agent and user context. These capabilities reduce incident response time, limit lateral movement when an agent is compromised, and support compliance by mapping actions back to accountable identities.

Key Takeaways

Make agents first‑class principals

Assign a verifiable identity to every agent to restore traceability and enable per‑agent revocation without breaking unrelated services.

Preserve user context with OBO

Use on‑behalf‑of exchanges where the system of record needs per‑user permissions; token pass‑through or agent credentials are options when appropriate.

Centralize policy, but manage gateway risk

Enforce allow‑lists and egress scopes at the gateway to reduce duplicated auth code; treat the gateway as critical infra with monitoring and SLOs.

Why shared keys break traceability and governance

Shared API keys and service accounts erase the distinction between individual agents and the actor behind a request. Logs show a credential, not an agent or a support engineer acting for a customer. At low scale this is inconvenient; at enterprise scale it’s dangerous. Unattributed changes to billing, medical records, or infrastructure create compliance gaps, complicate incident forensics, and force overly permissive policies that inflate risk.

How Agent Identity preserves user context across multi‑agent chains

Multi‑agent workflows commonly hop through orchestrators, tool agents, and MCP servers. Without identity propagation, the final system must either trust the intermediary or reject the request. Agent Identity supports token pass‑through when downstream systems trust the original token, OAuth2 client credentials when the agent must act as itself, and OBO exchanges that produce a token representing ‘agent acting for user’. This lets the system of record apply the correct per‑user permissions without modifying agents.

Policy, revocation, and least‑privilege enforcement at the gateway

An identity is only useful if you can act on it. TrueFoundry attaches allow‑lists to each agent (users, teams, apps, other agents) and egress permissions for models, MCP servers, and services. Remove a grant and the gateway returns a 403 immediately. By centralizing these controls you avoid brittle, duplicated access logic in agents and get a single place to audit, revoke, and tighten permissions as scale or risk changes.

Practical integrations and deployment patterns

TrueFoundry supports multiple identity models: TrueFoundry‑issued tokens for fast onboarding, or IdP‑backed identities mapped to subject claims in Okta, Entra, or any OIDC provider. It also supports SigV4 signing for AWS flows. Agents can run anywhere and still be governed: proxied agents get inbound policy enforcement, and embedded agents get outbound governance. For teams, that means incremental rollout is possible — register high‑risk agents first and expand coverage without rearchitecting deployments.

Risks and operational trade‑offs to watch

Identity at the gateway centralizes risk: token exchange, caching, and revocation become critical infrastructure. Expect new operational work (monitoring token lifecycle, scaling the gateway, and hardening the exchange paths). Also evaluate latency and failure modes for OBO flows and SigV4 signing under load. TrueFoundry addresses many of these concerns with token caching, refresh logic, and OpenTelemetry tracing, but platform teams must include the gateway in their SLOs and incident playbooks.

Frequently Asked Questions

How does Agent Identity affect existing IdP setups like Okta or Microsoft Entra?

Agent Identity can be TrueFoundry‑backed for quick onboarding or IdP‑backed so your existing Okta/Entra remains the source of truth. TrueFoundry maps agent registrations to subject claims and supports RFC‑compliant token exchanges (including OBO flows for Entra and Okta), preserving existing identity hygiene while adding agent‑level governance.

When should I use token pass‑through versus on‑behalf‑of?

Use pass‑through when the downstream system already trusts the caller’s token and needs the original user context intact. Use OBO when the downstream system requires a token that explicitly names both the agent and the user so it can enforce per‑user permissions. Client‑credentials (agent as itself) are appropriate for purely automated service calls where user context isn’t relevant.

What operational changes should platform teams expect when deploying Agent Identity?

Expect to add gateway monitoring, token lifecycle visibility, and SLOs for token exchange and signing operations. Plan incident playbooks for gateway failures and implement graceful degradation for low‑risk agents. You’ll also need processes for registering agents, mapping teams and owners, and rotating or revoking identities as part of normal platform hygiene.