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.

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.

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.

Registration Is the Enforcement Point

The reason to register agents in one place is not tidiness. It is that the gateways deny any caller that presents no registered identity, so the Agent Registry doubles as the enforcement point. Nothing acts anonymously, and the inventory is complete by construction.

Each registry entry carries four things: a verifiable identity, an accountable owner, a defined authority (the tools, models, and people it may reach or act for), and a lifecycle that covers credential rotation and a deprovisioning path. Whatever the agent is built on, Bedrock, Vertex AI, LangGraph, a custom HTTP service, or a copilot embedded in a SaaS product, it enters governance by being registered, with nothing to move or rewrite.

Because identity is required to act, revocation is surgical. Pull one agent's identity and it stops reaching every model and MCP server at once, while every other agent keeps running. That is the kill switch that a shared service account can never give you.

Agent Identity and Virtual Accounts, Working Together

Agents rarely act alone. The applications and services around them still need machine identities, and that is what virtual accounts are for. A virtual account is a non-user identity that an application or service assumes to reach resources, with a token you can auto-rotate, set rotation alerts on, and sync to your secret manager. The guidance is to create one virtual account per application and scope it to the minimum permissions it needs.

Put together, you get a clean separation of principals: people authenticate through your SSO, services and apps carry virtual accounts scoped to least privilege, and agents carry their own agent identities that can act for those people and services without ever losing attribution. Access decisions in all three cases are enforced at the gateway, and every call is inspected by AI agent guardrails for what it actually contains.

Note: Agent Identity on TrueFoundry is currently in beta, and gateway-issued per-hop token exchange is rolling out. Behavior may change as the feature matures.

Related reading

• AI Agent Registry how registration becomes the system of record for every agent
• AI Agent Guardrails inspecting what each agent hop actually contains
• What is MCP Authorization? the token and scope side of agent access
• MCP Server Security Best Practices hardening the tools agents reach
• MCP vs A2A how agents call tools and each other

Conclusion

An agent is not a person and it is not a static service, so it should not borrow either one's credentials. Give every agent its own AI agent identity and three hard problems get easier at once: you can attribute every action, scope each agent independently of the human driving it, and revoke a single rogue agent without downtime for the rest. On TrueFoundry that identity is created at registration and enforced at the gateway, so non-human identity stops being a spreadsheet of shared keys and becomes real infrastructure.

See how TrueFoundry issues and governs agent identity across your models, tools, and agents from one control plane. Book a demo or start free.