We know an agent needs an identity of its own instead of borrowing a person’s login or a shared service account. That statement is well known and easy to understand. The harder question is, what should that identity look like or contain.
A name in a config file, or a username anyone can use, is not an identity. So, what does an agent identity need?
The four properties
An agent identity shall comply with these four properties, and each answers a different question.
1. An agent needs its own identifier. Which agent is this?
Each agent gets a unique identifier that nothing else shares, neither another agent nor another person. If two agents use the same one, the logs cannot tell them apart, which is the exact problem we started with.
In practice, granularity is a design choice. One ID per agent type is easy to write policy against, while one per instance gives better attribution. A common failure is several agents inside one workload sharing one identity, so if you want them separate, you must split them deliberately.
2. An agent needs a way to prove itself. How do we know it is really that agent?
An identifier by itself is only a claim, because anyone can say they are that agent. The agent needs a credential that backs up the claim, ideally one tied to a cryptographic key, so knowing the name is not enough to pass as the agent.
With an X.509 credential, the private key never leaves the workload, and the agent proves itself by completing a handshake. With a JWT, the token is a bearer credential, so whoever intercepts it can use it until it expires.
3. An agent needs a short life. How long does a leak hurt?
Fixed credentials were a problem. The credential should expire on its own, in minutes or hours, and be replaced automatically without anyone remembering to do it. A credential that lives for a year turns every leak into a year-long problem.
4. An agent needs to get its credential without a secret. How did it get the credential in the first place?
This is the property most teams skip. If the agent must hold a secret just to ask for its credential, you have only moved the problem one step back. The better pattern is attestation: the platform the agent runs on vouches for it, and the agent receives its credential in return. No pre-shared secret sits in a file somewhere.
Attestation happens in two steps.
Step 1: the machine proves what it is. It uses evidence only the platform can produce, like a cloud instance identity or a Kubernetes service account token.
Step 2: the agent asks for its credential, and gets checked on how it runs. It asks for a small helper program on the same machine. That helper doesn’t ask for a password. It looks at where the request came from (which pod, namespace and service account) and compares that against a list of registered agents. If it matches, it hands back a short-lived credential.
The agent’s identity comes from where and how it runs, not from a secret it holds. If someone steals the config file, there’s nothing in it to use.
What is not on this list: permissions. An identity tells you who the agent is.
What it is allowed to do is a separate question, and we will come to it later in the series.
For now, the focus stays on identity, because everything that comes later depends on it. A permission decision only means something if you know for certain which agent is asking for it. So, the practical question is how to get there. A unique name, a key-backed credential, a short life and a way to receive it without a secret sound like a lot to build yourself. You don’t have to, because giving software, that isn’t a person, an identity is not a new problem.
Existing standards
That problem is called workload identity. A workload is a piece of software running somewhere, and workload identity is how that software gets an identity of its own. Existing standards already cover these four properties.
SPIFFE and SPIRE:
SPIFFE defines a standard identifier for a workload, written as a URI (Uniform Resource Identifier). For our agent it could be spiffe://example.org/agents/meeting-notes. The workload proves who it is with a short-lived document called an SVID, either an X.509 certificate or a JWT. SPIFFE’s Workload API hands these out without the workload holding a pre-configured secret, and keys rotate frequently and automatically. SPIRE is the implementation that does the attestation and issuing.
WIMSE:
A group at the IETF (Internet Engineering Task Force), the body that publishes internet standards, is writing a standard for how a workload’s identity and context get passed along when it calls other systems. The name stands for Workload Identity in a Multi System Environment. The draft names AI agents as one-use cases. It treats an agent as a workload acting on someone else’s behalf, so the agent is expected to stay within the limits of what it was given.
Read the four properties again. SPIFFE and SPIRE cover all of them: a unique identifier, a credential that proves it, short lifetimes, and issuance through attestation. WIMSE points in the same direction for how that identity travels between systems.
What they do not solve
- WIMSE is still a draft: The architecture document is an Internet-Draft with informational status, so it can change or be replaced. It points in a direction, but it is not a finished standard you can certify against.
- Built for services, not agents: A micro-service does the same job every time. An agent changes its path from Tuesday to Wednesday, which is why we called it a layer of its own. How well the standards fit that is still being worked out.
- A workload, not a behavior: If five agents run inside one workload, they share one identity unless you deliberately split them.
- Valid does not mean allowed: A clean, short-lived credential still does not mean the agent should be allowed to do everything it can reach.
- JWT replay: SPIFFE’s own documentation notes the JWT form of an SVID can be replayed if intercepted, which is one reason the certificate form is preferred.
Where to start
You do not have to adopt SPIFFE or SPIRE to begin. The four properties matter more than any product, and you can check your own agents against them today. For each agent, ask:
- Does it have an identifier nothing else shares?
- Does it prove that identity with a credential, not just a name?
- Does the credential expire and renew without a human?
- How did the agent get that credential in the first place?
If the answer to the last one is “there is a secret in a config file,” that is your first finding. It is also worth writing down who on your team owns each agent identity, since no standard will do that part for you.
Next post
In the next post, we will look at what happens when the agent acts for a person: how it can work on someone’s behalf without acting as them.