Root Auth: Authentication for Agents

For most of the internet’s history, identity has been designed around one assumption: the primary actor is human.

This assumption is breaking.

Agents browse, purchase, schedule, summarize, and call APIs on behalf of people and organizations, but an end to end authentication method for agents is nonexistent. Today, most agents are using wrappers around API keys, browser sessions and cookies, or OAuth tokens originally meant for humans. They can act, but they do not have a first-class identity of their own.

We need infrastructure where agents can be treated as first class actors on the internet: issuable, verifiable, scoped, and revocable.

The authentication flow we present is Root Auth.

The problem with current agent auth

Most existing systems force agents to work in one of three ways: reusing human credentials, holding API keys, or passing bearer tokens. All of these follow the existing principles of the web without improving the agent’s access to services.

A relying party needs to know:

• who is making this request
• who authorized that actor
• what it is allowed to do
• why it exists
• how long this authority is valid

Existing auth systems can answer some of those questions, some of the time. They were not designed to answer all of them for autonomous software actors.

What Root Auth does

Root Auth introduces a simple model: every agent is rooted in a trust anchor, but the agent itself is a first-class principal.

That trust anchor might be:

• a person
• an organization
• a device
• a verified phone number
• a domain

This base identity is the root.

An agent created under that root is not just “using the root’s token.” It gets its own identity and its own credentials, while bound to the root that authorized it.

Root Auth is the mechanism by which a root identity authorizes an agent identity, and an issuer turns that delegation into verifiable credentials.

It separates three things that are currently unified:

• the root identity
• the agent identity
• the token used for authentication

A person should not be indistinguishable from their agent. An organization should not have to issue raw secrets to every workflow. An agent should not only exist for the lifetime of one token.

Root Auth makes the relationship explicit:

• a root exists
• an agent is created under that root
• the relying party can verify that credential without calling the issuer on every request

Root Auth, step by step

Root Auth has four main phases: root establishment, agent creation, credential issuance, and relying party verification.

Establish the root identity

A root identity is first created as the trust anchor. This is the base where delegation begins. It could be a human, organization, device, or other identity class recognized by the system.

This does not mean the human is the only actor in the system. It means the human is the starting point of trust. The issuer signs this credential, and the relying party can later verify that signature using the issuer’s public key.

Issue an agent credential

After the root authorizes the delegation, the issuer mints an agent credential under Root Auth. That credential describes who signed it, which agent it is about, when it expires, who owns the agent, who delegated authority to it, what it can do, why it exists, what additional rules constrain it, and which exact token instance this is.

One optional configuration in Root Auth is domain-bound delegation. An agent credential can include an allowed domain that ties the agent’s authority to a specific domain or service namespace. If the agent is compromised, the issuer or operator can invalidate that routing or domain binding, causing future requests tied to that domain to fail policy checks at the relying party. This is not a replacement for token revocation via expiration, jti, or key rotation, but an additional way to revoke the token.

The agent is now independently identifiable, but still rooted in a chain of trust.

Verify at the relying party

When the agent calls a service, the relying party does not need to call the issuer every time. Instead, it can verify the credential locally using public key cryptography.

The relying party can now check:

• that the token signature is valid
• that the issuer is trusted
• that the token is not expired
• that the scope is sufficient for the requested action
• that the delegation claims make sense
• that the token or agent has not been revoked from the associated domain

If all checks pass, the relying party can safely say: this request is being made by agent agt_c82d1e4, which is rooted in hum_7f2ab91, for this purpose, under these rules.

Why “root” matters

An agent should not exist unbound through the network, because this is equivalent to the state of identity without an issuer. Agents are the delegated actors spawning from the root. Root Auth is the bridge between the two.

If agents are going to participate in the internet economy, they need identity primitives that establish a chain of trust.

Root Auth is the protocol built for autonomous actors on the web.