Agents Need Identity. Agent Auth Has the Shape.

Your agent just called a production API, and the service has no idea what it is.

The request has a valid token. The signature checks out. The API gateway lets it through. But none of that answers the question that matters during an incident: which agent acted, what was it allowed to do, and who approved it?

That’s the same gap behind The Agent Did It. But the Logs Say You Did.. Agents keep borrowing human tokens, shared service accounts, and static API keys because most products still don’t have a first-class concept of an agent.

It works until the agent does something expensive, weird, or destructive.

Then the logs blame the human. The service account gets rotated. Nobody knows which workflow actually acted. And the “AI agent” turns out to be invisible inside the one system that matters most: identity.

Agent Auth Protocol is interesting because it tries to make that invisible actor real.

The contract an agent service needs

Before a service lets an agent act, it needs a small contract.

Not a policy document. Not a prompt instruction. A thing the product can enforce.

At minimum, the service should know:

• who the agent is
• which host, app, or user introduced it
• whether it acts for a user or autonomously
• which capabilities it requested
• which capabilities were approved
• what constraints apply to those capabilities
• how long the grants last
• how to audit and revoke the agent

That’s the useful way to read Agent Auth.

Don’t start with “should I install this package tomorrow?” Start with “is this the shape my own agent identity layer needs?”

Because the shape is strong.

It has discovery, so a service can advertise that it supports agents. It has registration, so agents aren’t anonymous scripts. It has capabilities, so access is narrower than “API token.” It has approval methods, so sensitive grants go through a real gate. It has short-lived signed tokens, so execution is bounded. It has revocation, so one bad agent can be killed cleanly.

That’s the part I would steal even if I didn’t adopt the implementation.

What the shape looks like

In the current Better Auth implementation, discovery starts at /.well-known/agent-configuration or the Better Auth route /api/auth/agent/agent-configuration.

The important detail: the field is version, not agent_auth_version.

{
  "version": "1.0-draft",
  "provider_name": "support-api",
  "description": "Support operations for AI agents",
  "issuer": "https://support.example.com/api/auth",
  "default_location": "https://support.example.com/api/auth/capability/execute",
  "algorithms": ["Ed25519"],
  "modes": ["delegated", "autonomous"],
  "approval_methods": ["ciba", "device_authorization"],
  "endpoints": {
    "register": "https://support.example.com/api/auth/agent/register",
    "capabilities": "https://support.example.com/api/auth/capability/list",
    "execute": "https://support.example.com/api/auth/capability/execute",
    "request_capability": "https://support.example.com/api/auth/agent/request-capability",
    "status": "https://support.example.com/api/auth/agent/status",
    "revoke": "https://support.example.com/api/auth/agent/revoke",
    "introspect": "https://support.example.com/api/auth/agent/introspect"
  }
}

That document tells the agent where to register, where to list capabilities, where to execute, and which approval modes the service supports.

The capabilities themselves come from /capability/list:

{
  "capabilities": [
    {
      "name": "ticket.read",
      "description": "Read support tickets",
      "approval_strength": "none",
      "input_fields": [
        { "name": "ticket_id", "type": "string" }
      ]
    },
    {
      "name": "ticket.close",
      "description": "Close a support ticket",
      "approval_strength": "session",
      "input_fields": [
        { "name": "ticket_id", "type": "string" },
        { "name": "priority", "type": "string" }
      ]
    }
  ],
  "has_more": false
}

Now the agent isn’t asking for “the support API.” It’s asking for ticket.read or ticket.close.

When a capability needs a tighter boundary, the request can carry constraints:

{
  "capabilities": [
    "ticket.read",
    {
      "name": "ticket.close",
      "constraints": {
        "priority": { "not_in": ["critical"] }
      }
    }
  ]
}

That’s the difference between agent access and normal API access.

Normal API access says “this token can call this service.” Agent access needs to say “this specific agent can perform these specific actions, under these constraints, after this approval, until this grant expires.”

That’s the part most products don’t have yet.

Why Agent Auth looks serious

The repo itself isn’t the credibility signal. It’s still small. The Better Auth ecosystem behind it is.

On May 3, 2026, Better Auth had more than 28,000 GitHub stars, about 2,500 forks, an MIT license, active development, and a real TypeScript auth community around it. That doesn’t automatically make every plugin production ready, but it does mean this isn’t a random weekend repo with a protocol domain attached.

The Agent Auth side has real artifacts too: an implementation repo, a protocol repo, Better Auth server plugin docs, and published npm packages for @better-auth/agent-auth and @auth/agent.

The code also has the right security vocabulary in the right places.

It uses signed JWTs with short lifetimes. It checks token type and audience. It has jti (token ID) replay protection. It models revoked agents, revoked hosts, expired sessions, and revoked grants. It supports capability constraints. It has approval flows. It has WebAuthn-gated approval tests for higher-risk capabilities. It has JWKS (JSON Web Key Set, the public-key bundle services publish for verification) cache tests and blocking meant to keep key fetches away from local or private network targets.

That’s not proof of security. But it’s proof that the authors are thinking about the right failure modes.

Toy auth code usually fails a much simpler test: it only handles the happy path.

Agent Auth doesn’t look like that. The repo has tests for replay, revoked agents, audience mistakes, constraint validation, host revocation cascades, WebAuthn approval, and back-channel approval behavior that avoids leaking whether a user exists. Those aren’t marketing features. They’re the annoying details you add when you know auth systems fail in boring ways.

How it fits with MCP and ACP

This isn’t really competing with MCP or ACP.

ACP is about how editors talk to coding agents. MCP is about how agents connect to tools and data. Agent Auth is about who the agent is when it asks for access, what it is allowed to do, and how that permission gets approved or revoked.

Different boundary.

That’s why Agent Auth is more interesting for security teams than another editor integration protocol. It sits at the point where agent autonomy becomes an identity problem.

If agents are going to call your product, open tickets, move money, rotate infrastructure, read customer records, or deploy code, the product needs a better answer than “the request came from Amit’s token.”

Honest trade-offs

Agent Auth adds friction.

Borrowing a user token is easy. A shared service account is easy. A static API key in an environment variable is easy. That’s why every company ends up with them.

Agent identity is slower. You need registration, grants, approval UX, token verification, key rotation, audit storage, and revocation paths. You need to decide what your capabilities are, which is harder than exposing your whole API.

The implementation is early too.

The Agent Auth implementation repo had around 30 stars and 3 forks when I checked it on May 3, 2026. The protocol repo had around 138 stars and 8 forks. The Better Auth docs say the plugin is under heavy development and may change. There are open PRs touching meaningful auth behavior, including endpoint namespacing and host JWT registration lookup.

Those aren’t “run away” signals. They’re “pre-1.0 infrastructure” signals.

I also wouldn’t call it a standard yet. There’s a working draft, docs, repos, and official implementations, but I didn’t find signs of broad production adoption, independent audit, standards-body ownership, or mature conformance tooling. There’s even an open issue proposing a conformance test CLI.

If you adopt it today, review the code, pin versions, and treat upgrades as security-relevant.

But the alternative is pretending agents are just users, scripts, or service accounts.

They’re not.

An agent can act for a user without being the user. It can run autonomously without being a generic backend job. It can make decisions without being a human. That makes it a new kind of actor, and new actors need a real identity model.

Agent Auth is not finished. It isn’t battle-tested enough to crown as the standard.

But before your agent calls another service, ask the service one question: do you know what an agent is?

If the answer is no, this is the shape that fixes it.