How Identity Works for AI Agents

Suppose Maya asks an AI agent to change a hotel reservation. The agent opens the hotel's booking system, finds the reservation, and requests a different date. It knows the right details and appears to be acting for the right person. The hotel still has to decide whether to trust it.

If Maya were making the request herself, the hotel could ask her to sign in. An agent complicates that familiar pattern. It is software acting for someone else, it may run on infrastructure neither Maya nor the hotel controls, and it may return later with a different task. A useful response therefore needs more than a convincing sentence that says, “I work for Maya.”

We tend to call this an agent identity problem. That label is convenient, but it hides several decisions inside one phrase. Before looking for a universal identity system, it helps to separate those decisions.

#“Who are you?” is a bundle of questions

When a service asks an agent who it is, the answer is assembled from several facts. Is this the same agent, or at least the same cryptographic key, that appeared yesterday? Who operates it? Which person or organization asked it to act? What has it actually been allowed to do?

These facts are related, but none automatically supplies the others. Proving that two requests came from the same key does not reveal who controls that key. Connecting an agent to Maya does not give it permission to read every document in her account. Granting permission to change one reservation does not make the agent trustworthy in every future situation.

There is also a question that technology alone cannot settle: who is responsible if the agent gets the decision wrong? A credential can make an action easier to trace, but responsibility depends on the people, companies, agreements, and policies around the agent. Identity can support accountability without creating it.

This is why the search for one digital passport is misleading. Different services face different risks, and even one service may ask for different evidence depending on the action. Reading public information, changing a reservation, and moving money should not require identical levels of trust.

#Auth.md lets a service form its own relationship

Auth.md is an open approach to agentic registration. It gives a service a standard way to publish instructions for agents, evaluate an introduction, and issue its own credentials. The goal is not to give every agent one identity card that every website must accept. It is to make the first meeting between an agent and a service more predictable.

The process begins with discovery. A service publishes information that tells an agent where registration happens, which forms of identity it accepts, and which permissions are available. The agent can read those instructions before attempting to act. This matters because today's alternative is often guesswork, a human login flow, or a custom integration built separately for every service.

The introduction can take several forms. If the agent comes from a provider the service trusts, that provider can issue a signed statement connecting the agent to a known user. The underlying proposal is the Identity Assertion JWT Authorization Grant, often shortened to ID-JAG. The name is technical, but the idea is simple: one trusted system introduces the agent, while the receiving service still makes its own decision.

If no trusted provider can make that introduction, Auth.md supports a direct claim process. The service gives the agent a short code and a link. The agent shows both to Maya, Maya signs in to the service, and she confirms that this is the agent she wants to connect. Auth.md can also allow an agent to begin with limited anonymous access and be claimed later, which gives services room to match the amount of identity they request to the amount of risk involved.

After the introduction or claim, the service issues an access token with specific permissions, usually called scopes. The token belongs to the agent's relationship with that service. Maya does not have to hand over her password, and the agent does not simply become Maya. The service can limit the token, refresh it, or revoke it without disturbing Maya's own account.

That separation is the most important part of Auth.md. Identity may come from a provider or a person, but authorization remains local. A trusted introduction can help a service understand who is arriving. It does not force the service to grant access.

#A signed request answers a different question

Once the service has registered an agent, it still needs confidence in the requests that agent sends. A stolen access token could be copied. A message could be altered. Another program could claim to be the same agent.

Web Bot Auth addresses this narrower problem by having an agent sign web requests with a private cryptographic key. The service uses the corresponding public key to check the signature. If important parts of the request changed after signing, or if the sender did not control the private key, the check should fail.

This is sometimes compared with signing a letter, and that analogy is useful up to a point. The signature proves control of a key and protects the parts of the request that were signed. It does not prove that Maya approved the action, that the agent has permission to perform it, or that the action is wise.

VestAuth makes this approach concrete. It creates a key pair for an agent and signs requests using the developing Web Bot Auth protocol, which builds on the established HTTP Message Signatures standard. VestAuth is an implementation of the underlying idea, not a separate answer to every part of agent identity.

Web Bot Auth and Auth.md are therefore not direct substitutes. Auth.md helps a service establish and govern a relationship with an agent. Web Bot Auth helps prove that a particular request came from the holder of a particular key. A service could use both, just as it could accept Auth.md credentials without requiring signed requests for every low-risk action.

The distinction is also a useful guardrail. Web Bot Auth is still an Internet-Draft, and its own design leaves authorization, delegation, and consent to other systems. A valid signature should never be mistaken for permission.

#Other systems answer other parts of the question

Consider an agent running inside a company’s managed infrastructure. The receiving service may care less about the individual software process and more about whether the call came from a workload the company recognizes. SPIFFE is built for this setting. It gives workloads identities within an organization’s trust domain and credentials that can prove those identities.

SPIFFE can answer, “Which managed workload is calling?” It does not automatically answer, “Which customer asked it to act?” A company-operated agent serving thousands of users may have a strong workload identity while still needing another way to connect each action to the right person.

OAuth and OpenID Connect begin from the human account. They are the familiar reason an application can ask for limited access to your calendar or profile without receiving your password. For agents, they can establish whose account approved access, but they may say little about which agent instance is using that access right now.

UCAN begins from permission rather than biography. It allows a specific capability to be delegated and verified, such as the ability to read one folder or collect one package before a deadline. In some situations, the service does not need a rich description of the agent at all. It needs reliable evidence that this exact power was granted through an acceptable chain.

These approaches can look like competitors when they are grouped under the word identity. They become easier to understand when each is attached to the question it answers. SPIFFE identifies a managed workload. OAuth and OpenID Connect connect access to an account. UCAN carries delegated authority. Web Bot Auth authenticates a request from a key. Auth.md gives a service a process for registering an agent and issuing local credentials.

#Identity will probably be layered

An agent may eventually carry several kinds of evidence at once. It might have credentials from the service, a cryptographic key for signing requests, a connection to a human account, and a narrowly delegated capability for one task. That is more complicated than a universal passport, but it reflects the way trust actually works.

The service then decides which combination is sufficient. A public search may require no identity. Saving a preference might require a basic agent account. Accessing private records could require a clear connection to a person and a signed request. Moving money may require all of that plus fresh human approval.

This gradual approach leaves room for the equivalent of guest checkout. Not every useful interaction needs a permanent account or a detailed identity profile. Services can allow small, reversible actions first and request stronger evidence as the stakes rise. The important design choice is not maximum identity; it is proportionate trust.

Layering does create work for services. They must decide which providers to trust, which permissions to offer, how credentials expire, and what happens when a user disconnects an agent. Protocols can make those decisions easier to express and automate, but they cannot make the policy choices disappear.

#Identity makes trust possible, not automatic

A well-identified agent can still misunderstand a request. A properly signed message can still contain a bad instruction. A tightly scoped permission can still be used at the wrong time.

Identity and authentication help a service know what it is dealing with. Authorization limits what the actor may do. Signatures make certain kinds of impersonation and tampering harder. Together, these controls can make agent behavior more constrained and more traceable.

They do not prove competence, judgment, or good intent. Those qualities require other signals, such as past behavior, human oversight, transaction limits, review steps, and clear responsibility when something goes wrong. Strong identity is part of a trust system, not a replacement for one.

#The useful question is not which protocol wins

The emerging agent identity landscape makes more sense once we stop asking every technology to solve the whole problem. Auth.md is valuable because it gives agents and services a common way to begin a relationship. Web Bot Auth can strengthen the authenticity of individual requests. SPIFFE, OAuth, OpenID Connect, and UCAN can contribute different evidence about the software, the person, or the authority behind an action.

The likely future is not one credential that follows an agent everywhere and answers every question. It is a set of proofs that can be combined according to context, with each service deciding what it needs and what it is willing to trust.

That may sound less elegant than a universal passport. It is also more honest. “Who are you?” has never been answered by one fact, especially when the one asking is a service and the one answering is software acting for someone else.