AI Agent Identity: Giving Every Agent a Non-Human Identity

What Is AI Agent Identity?

AI agent identity is the verifiable credential a registered agent presents on every call it makes. It answers a question tokens alone cannot: not "was a valid credential presented" but "which agent is calling, and who is it acting for right now."

TrueFoundry already recognizes two kinds of principal, and an agent identity is a third.

The line that matters is delegation. A virtual account can only ever act as itself, so point one at an MCP server and every call looks the same no matter who prompted it. An agent identity can act on behalf of someone else, so a single registered agent that serves hundreds of people still makes calls that stay attributable to whoever each request is for, while remaining identifiable as the agent. That is the property that makes agent traffic auditable.

Non-human identity, and why it is its own category

"Non-human identity" (NHI) is the umbrella term security teams use for anything that authenticates without a person behind it: service accounts, workload identities, API clients, and now agents. Agents are the hardest members of that family, because unlike a fixed service account they behave autonomously. They interpret context, pick tools, and chain calls, so their governance needs everything a service account needs (credential rotation, inventory) plus a few things it never did: delegation rules, an accountable owner, per-hop attribution, and a kill switch.

Treating an agent as "just another service account" is the mistake that leads to over-privileged agents no one can trace. Non-human identity management for agents starts by giving each one a first-class identity of its own.

Why Every Agent Needs Its Own Identity

Giving each agent a distinct identity is one decision that unlocks the whole governance model.

• Attribution. The receiver of a call can tell whether the caller is a human, a service, or a specific agent. Actions become provable after the fact, which is what an audit actually requires.
• Per-agent policy. One person drives many agents, and they should not all inherit that person's full reach. Jane's support copilot that reads Jira and her engineering agent that writes to it are different principals, even though both act for Jane. Distinct identities let you scope them differently.
• No anonymous agents. If an agent can only reach a tool by presenting a registered identity, then registration becomes the enforcement point. You get an org-wide inventory for free, and you can revoke one rogue agent without touching the rest.

That last point is the quiet payoff. Once identity is required to act, the registry stops being documentation and becomes the chokepoint that makes every other control possible.

How TrueFoundry Issues and Governs Agent Identity

On TrueFoundry, an agent identity is not a separate object you create and bolt on. It is a step in registering the agent, so the identity and the agent are one to one. Register the agent and its identity comes into being. Delete the agent and the identity goes away with it.

‍

Product screenshot, TrueFoundry docs: the Agent Identity step of agent registration.

Where the credential comes from

During registration you choose how the agent proves who it is:

‍

• TrueFoundry-backed. TrueFoundry issues and signs the agent's token. This is the simplest option and the right default for agents you build and run yourself.
• Identity provider-backed. The agent authenticates with a token from your own provider, such as Okta, Microsoft Entra, any OIDC provider, or a SPIFFE and SPIRE endpoint. You map specific claim values to the agent so an incoming token resolves to it. This path unlocks On-Behalf-Of (OBO) delegation, so the agent can carry a user forward through the chain.

‍

The identity means the same thing either way. Only the issuer differs, and you can mix issuers per agent inside one tenant.

TrueFoundry as the identity broker

When your identity provider has no agent-identity capability yet, TrueFoundry can play all three control-plane roles. It issues each agent's identity, authorizes every call at the Agent Gateway and MCP Gateway, and, with token exchange, mints a scoped credential for each hop. Your enterprise SSO keeps doing what it already does, which is authenticating human users. On a call, the agent presents its own identity alongside the user's, so both are visible at the same time:

‍

curl https://gateway.truefoundry.ai/api/llm/chat/completions \

  -H "Authorization: Bearer $USER_TOKEN" \

  -H "x-tfy-agent-authorization: $AGENT_TOKEN" \

  -H "Content-Type: application/json" \

  -d '{

        "model": "openai-main/gpt-4o",

        "messages": [{"role": "user", "content": "Summarize my open issues"}]

      }'

‍

The agent fetches its own token from the registry (the Get Token action on the agent), the same way a virtual account does.

Who an agent is allowed to act for

Delegation is not unbounded. It is scoped by the agent's collaborators, set on the Access Control step of registration. The same list that decides who may invoke the agent also decides who the agent may act for.

‍

Product screenshot, TrueFoundry docs: agent collaborators and roles.

‍

An Agent Manager can edit the agent. Agent Access can invoke it and be acted for by it. An Owner team, set separately, stays accountable for the agent from creation to retirement. Those grants are the agent's defined authority: which people it may act for, and which MCP servers and models it may reach.

‍