What AI agent identity management answers
Discover found the agents. The next question a security team asks is: which agent made this request, and who answers for it? Today most services hand every agent one shared key, so that question often has no answer.
AI agent identity management is the control that gives each agent a name it can prove and a person who is accountable for it. AgentFort Identity does this without asking teams to rebuild how their agents sign in. It follows one rule:
- If an agent already has an identity, use it.
- If it signs in through an identity provider, plug into that provider.
- If nothing exists, AgentFort issues a SPIFFE identity itself.
In the recorded demo, the identity console for Northwind, a simulated company, showed a plan for every agent Discover had found: where its identity comes from, its SPIFFE ID and its owner. For vendor-neutral background, read our guide to AI agent identity.
The 3 identity paths at a glance
| Path | When it applies | How the agent proves who it is | Demo example |
|---|---|---|---|
| 1. Cloud identity | The agent runs with an AWS role or a Google service account | It signs a request with its own credentials, and the cloud confirms who it is | An agent with an AWS role gets a certificate named after its role, valid for 5 minutes |
| 2. Identity provider | The agent signs in through Microsoft Entra ID, Okta or SPIRE | AgentFort plugs into the provider the agent already uses | Support Triage, an Entra app that trusts its Kubernetes service account |
| 3. Nothing exists | No cloud role and no login | The AgentFort host agent identifies the calling program, and the owner approves it | A batch job gets a SPIFFE identity after its owner approves |
Path 1: an existing cloud identity
An agent that runs with an AWS role already has a strong identity. It signs a request with its own credentials. AgentFort passes that request to AWS unchanged, and AWS confirms who it is. The secret never leaves the agent. The agent then gets a certificate named after its role, valid for 5 minutes. Google service accounts work the same way.
Path 2: your identity provider
Support Triage is a Microsoft Entra app that trusts its Kubernetes service account, so it stores no secret. Microsoft calls this pattern workload identity federation and describes it as access to Entra-protected resources "without managing secrets". The assistant on Priya's laptop signs in with Okta and acts for her, so AgentFort knows both the agent and the person behind it. Teams already running SPIRE keep their identities, and other providers plug in the same way.
Some agents have more than one identity. When that happens, AgentFort picks the strongest and shows why.
Path 3: a SPIFFE identity when nothing exists
Some agents have no cloud role and no login, like Northwind's batch job. Here, the AgentFort host agent on that machine asks the kernel which program is calling, down to the script and its code.
Nothing is issued until the owner approves, and they see exactly what they are approving, including the code. With a single approval, only this program gets the identity. If its code changes, the identity stops until someone accepts the change. An agent that nobody owns gets no identity at all.
Proof on every request
The AgentFort gateway trusts SPIFFE certificates. Give it the trust bundle, and every agent, whichever path it took, proves who it is on every request. That identity is what the rest of AgentFort keys on: Access grants are written per agent, and every receipt records the identity behind the request.
What Identity doesn't do, and what you still need
Identity proves who an agent is and who owns it. It doesn't decide what the agent may do; that is AgentFort Access. It relies on the identity sources you already run, so their configuration still matters. Path 3 identities need an owner's approval, and an agent without an owner stays without an identity until someone claims it.
- Name an owner for every agent Discover finds.
- Decide who may approve a new program identity, and who accepts code changes.
- Move agents off shared keys once each one has its own identity.
- Give the AgentFort gateway the SPIFFE trust bundle.
How Identity connects to the other controls
AgentFort Discover supplies the agents, and Identity turns each one into a named, owned workload. Discover and Identity together make up AgentFort's Identity control. AgentFort Access then grants each identity specific operations, including acting for a person: an assistant acting for Priya can update Priya's cases but not Lena's. AgentFort Data Protection and AgentFort Isolation govern what moves through each agent's calls and what its code can reach. Visibility records the identity on every receipt. The AI agent security guide shows how the controls fit together.
Give every agent a name and an owner
Request a demo to see the 3 identity paths applied to agents like yours, or join the design partner program to deploy AgentFort Identity alongside the identity provider you already run.
Video transcript
Discover found the agents. Now each one needs a clear identity: a name it can prove, and a person who answers for it. AgentFort follows one rule. If an agent already has an identity, use it. If it signs in through an identity provider, plug into that provider. And if there's nothing at all, AgentFort issues a SPIFFE identity itself. This is the identity console for Northwind. Every agent that Discover found already has a plan: where its identity comes from, its SPIFFE ID, and its owner.
Path one. The agent already has a cloud identity. This one runs with an AWS role. It signs a request with its own credentials, AgentFort passes it to AWS unchanged, and AWS confirms who it is. The secret never leaves the agent. It gets a certificate named after its role, valid for five minutes. Google service accounts work the same way. Path two. The agent signs in through an identity provider. Support Triage is a Microsoft Entra app that trusts its Kubernetes service account, so it stores no secret.
The assistant on Priya's laptop signs in with Okta and acts for her. Teams running SPIRE keep their identities, and other providers plug in the same way. When an agent has more than one identity, AgentFort picks the strongest and shows why. Path three. Nothing exists. This batch job has no cloud role and no login. The AgentFort host agent on its machine asks the kernel which program is calling, down to the script and its code.
Nothing is issued until the owner approves, and they see exactly what they approve, including the code. One click, and only this program gets the identity. If its code changes, the identity stops until someone accepts it. And an agent that nobody owns gets no identity at all. The AgentFort gateway already trusts SPIFFE certificates. Give it this bundle, and every agent, whichever path it took, proves who it is on every request.
Frequently asked questions
What is SPIFFE, and why use it for AI agents?
SPIFFE, the Secure Production Identity Framework for Everyone, is a set of open-source standards for securely identifying software. It defines short-lived cryptographic identity documents called SVIDs. For an agent, that means a verifiable name that expires quickly instead of a long-lived shared key. AgentFort issues a SPIFFE identity only when an agent has no cloud or identity-provider identity, and its gateway trusts SPIFFE certificates.
Does AgentFort Identity replace my identity provider?
No. AgentFort uses the identities you already have. An agent with an AWS role or a Google service account keeps it. An agent that signs in through Microsoft Entra ID or Okta keeps signing in there, and teams running SPIRE keep their identities. AgentFort issues its own SPIFFE identity only when nothing else exists, and only after the agent's owner approves it.
What is the difference between a non-human identity and an AI agent identity?
A non-human identity is any credential that software uses, such as a service account, an API key or a cloud role. An AI agent identity is a non-human identity tied to one specific agent, with an owner who answers for it and, when the agent works for someone, the person it acts for. A key shared by several agents is a non-human identity too, but it can't tell you which agent made a request.