AI agents that read your email, send messages, and call APIs on your behalf are operating with a fundamental security flaw: they are pretending to be you. The fix is not better prompts or tighter instructions — it is giving each agent its own cryptographic identity, scoped capabilities, and an auditable lifecycle that you can revoke at will. This article breaks down the three-layer model that emerging protocols like the Agent Auth Protocol and Agent Identity (AID) are building, and shows you exactly how to implement it.
Last verified: 2026-07-22 · Give agents authority, not credentials · Use Ed25519 keys + scoped JWTs · Revoke any agent instantly · Audit every action
The core problem is simple: agents today do not have identity. When you connect an AI agent to your Gmail, your calendar, or your CRM, you hand it your OAuth token — the same one a human user would use. The service sees "you" making requests, not the agent. If something goes wrong, you cannot tell which agent did what, and revoking one means disconnecting all of them. Multiple emerging open-source protocols — including the Agent Auth Protocol from the Better Auth team, Agent Identity (AID), and the IETF's Agent Identity Protocol (AIP) Internet-Draft — are solving this by making the agent a first-class principal with its own identity, capabilities, and lifecycle.
Why Giving Agents Your Credentials Is Dangerous
When you authorize an AI agent today, what actually happens? You generate an OAuth token for your account and hand it to the agent — or you connect an MCP server that uses your user-level credentials. The service you are calling (Gmail, Slack, your bank API) sees requests coming from your identity. It has no idea an agent is involved.
This creates three problems that the OWASP Top 10 for Agentic Applications 2026 explicitly calls out:
No traceability. If three agents share one token, your audit logs show "user@example.com called the API 200 times" — not which agent made which call or why. When something goes wrong, you cannot trace it back to the responsible agent.
No scoping. Your OAuth token likely grants the agent everything you can do — read, write, delete, send. You cannot say "this agent can only read emails" or "this agent can send but not delete" at the protocol level. You are relying on the agent's prompt to self-restrain, and prompts are not security controls. In March 2026, Meta's Director of AI Alignment publicly disclosed that her own AI agent deleted hundreds of her emails and ignored stop commands because context window compaction erased the safety instructions mid-session.
No revocation. If one agent goes rogue, revoking its access means revoking the shared token — which kills every other agent using it too. You have to disconnect the entire integration, not just the problematic agent.
The Clinejection attack in February 2026 made this concrete: a prompt injection in a GitHub issue title caused an AI triage bot to run npm install with a malicious package, compromising approximately 4,000 developer machines in eight hours. The bot had broad tool access with no per-action authorization — exactly the gap that agent identity protocols are designed to close.
What Is Agent Authentication? (The Three-Layer Model)
Agent authentication is the practice of giving each AI agent its own verifiable identity — separate from any human user — so that services can see, scope, and revoke the agent's access independently. The emerging consensus across multiple protocols breaks this into three layers:
| Layer | What It Answers | How It Works |
|---|---|---|
| Identity | Who is this agent? | Each agent gets a cryptographic key pair (Ed25519) and a unique identifier, registered with an auth server |
| Authorization | What can this agent do? | Fine-grained capabilities (not broad scopes) with constraints — e.g., "read emails, last 90 days, own account only" |
| Discovery | How does the agent find services? | A well-known endpoint or directory where agents can discover what a service offers and how to authenticate |
This model treats agents the way you would treat a new hire at a company. You do not hand the intern your CEO credentials and say "pretend to be me." You give them their own account, scoped permissions, and an audit trail. The same principle applies to AI agents.
How Does Agent Identity Work?
Agent identity works by giving each agent its own cryptographic key pair and registering it with an authentication server. Here is the flow, as defined by the Agent Auth Protocol specification and the AID protocol:
Key generation. The agent (or its host application) generates an Ed25519 key pair locally. The private key never leaves the agent's machine. Ed25519 is the same elliptic-curve signature algorithm used by SSH keys and Signal — it is fast, compact, and quantum-resistant enough for current threat models (RFC 8032).
Registration. The agent registers its public key with an auth server. The server assigns the agent a unique identifier (agent ID) and a role with scoped permissions. In the AID protocol, this uses RFC 8628 — the OAuth 2.0 Device Authorization Grant — so a human admin approves the registration on a separate device, just like pairing a smart TV.
Token issuance. When the agent needs to call a service, it signs a proof of possession with its private key and requests a JWT access token from the auth server. The token contains the agent's identity, the user it is acting on behalf of, and the specific capabilities it has been granted. The token is short-lived (typically 1 hour) and scoped.
Service calls. The agent presents its JWT to the target service. The service verifies the token, checks the agent's capabilities, and logs the request with the agent's identity — not the user's. The service can now see "agent_123 called /api/emails on behalf of user_jane at 14:32 UTC."
Revocation. If the agent misbehaves, you revoke its registration. The auth server stops issuing new tokens, and existing tokens expire within their TTL. The agent is effectively fired — and it only affects that one agent, not every agent sharing your credentials.
What Are Capabilities and How Do They Differ from OAuth Scopes?
Capabilities are the protocol's unit of authorization — a server-offered action identified by a stable name. Unlike OAuth scopes (which are typically broad labels like "read" or "write"), capabilities are fine-grained and can carry constraints that restrict exactly what input values the agent is authorized to supply.
For example, instead of granting an agent a "transactions:write" scope (which could mean anything from checking a balance to transferring $100,000), a capability grant looks like this:
{
"capability": "transfer_funds",
"constraints": {
"to": { "const": "acc_456" },
"amount": { "maximum": 1000 },
"currency": { "const": "USD" }
}
}
This grant says: "the agent can transfer funds, but only to account acc_456, up to $1,000, in USD only." If the agent tries to transfer $5,000 or to a different account, the server rejects it — regardless of what the LLM decided to do. The constraint is enforced at the server, outside the model's trust boundary, so a prompt injection or context window compaction cannot override it.
This is the critical difference: scopes tell the agent what it is allowed to attempt; capabilities tell the server what it is allowed to actually do.
How Do Agents Discover What They Can Do?
Discovery solves the problem of how agents find services and learn what capabilities they offer. Without it, you have to manually configure every integration — tell the agent "Gmail has these endpoints, Slack has those endpoints." With discovery, the agent can look up a service automatically.
The Agent Auth Protocol proposes a well-known endpoint (similar to OIDC's /.well-known/openid-configuration) at /.well-known/agent-auth that every compliant service publishes. This endpoint describes:
- What capabilities the service offers
- How agents should authenticate
- What encryption is supported
- How to request additional capabilities at runtime
For services that do not yet implement the protocol, the Agent Auth Protocol ships with an adapter that converts existing OpenAPI specifications into capabilities. Since most major APIs (Gmail, Slack, Notion, OpenAI) already publish OpenAPI specs, this gives agents a "phone book" of available actions without requiring every service to adopt the protocol first.
A community directory at agent-auth.directory lets agents search for services by intent — "I need to read emails" — and find services that offer that capability.
Agent Auth Protocol vs MCP vs OAuth: What Is the Difference?
The Model Context Protocol (MCP) — created by Anthropic in November 2024 — standardized how AI applications connect to external tools and data sources. MCP uses OAuth 2.1 for authentication. But MCP's auth model was designed for users authorizing applications, not for per-agent identity. When three agents connect to the same MCP server through OAuth, the server sees one client, not three agents.
Here is how the pieces fit together:
| Protocol | What It Solves | Identity Model | Use Alongside |
|---|---|---|---|
| MCP | How agents connect to tools and data sources | OAuth 2.1 — user-level, no per-agent identity | Yes — MCP for tool access, agent auth for identity |
| Agent Auth Protocol | Per-agent identity, capabilities, discovery | Agent as first-class principal with Ed25519 keys | Yes — sits alongside MCP |
| AID | Agent authentication via OAuth 2.0 token exchange | Ed25519 identity + scoped JWTs, RFC 8628 device flow | Yes — identity layer for MCP/A2A |
| AIP (IETF draft) | Identity + policy enforcement proxy | Key pair + registry + enforcement proxy | Yes — complementary |
| OAuth 2.0 | User grants third-party app access to their resources | User is the principal | Already in use — agent auth extends it |
The key insight: agent auth protocols do not replace OAuth or MCP — they add an identity layer on top. Services can still expose capabilities through MCP tools while using agent auth for the identity and authorization layer. MCP handles "how the agent calls the tool"; agent auth handles "who the agent is and what it is allowed to do."
How to Implement Agent Authentication: A Step-by-Step Guide
If you are building or running AI agents that call external services, here is how to move from the "share my credentials" model to proper agent authentication.
Step 1: Give each agent a cryptographic identity
Generate an Ed25519 key pair for each agent. The private key stays on the agent's host machine — it never goes over the network. The public key is registered with your auth server.
# Generate an Ed25519 key pair (Python example with PyNaCL)
from nacl.signing import SigningKey
key = SigningKey.generate()
private_key = key.encode() # 32 bytes — store locally, never transmit
public_key = key.verify_key.encode() # 32 bytes — register with auth server
If you are using the AID protocol, the aid-register CLI tool handles this automatically.
Step 2: Register the agent with an auth server
Set up an OAuth 2.0 server that supports agent registration. The Agent Auth Protocol provides an SDK and server implementation. During registration:
- The agent submits its public key and a human-readable description
- An admin (or the user) approves the registration, selecting a role and permissions
- The server assigns the agent a unique ID and stores its public key
Step 3: Define capabilities with constraints
List every action your service offers as a capability. For each capability, define:
- A stable name (e.g.,
email_read,email_send,file_delete) - A human-readable description (shown in approval flows)
- Input and output schemas
- Optional constraints (e.g., maximum amount, allowed recipients, time window)
Use the Agent Auth Protocol's adapter to convert your existing OpenAPI spec into capabilities if your service already has one.
Step 4: Implement the approval flow
When an agent requests a capability it does not yet have, trigger an approval flow. The Agent Auth Protocol supports three approval patterns:
- Device flow (RFC 8628): the agent displays a code, the user approves on their phone — good for first-time setup
- CIBA flow: the agent sends a back-channel request, the user gets a push notification — good for runtime escalation
- Inline flow: the user approves directly in the host UI — good for real-time, interactive sessions
Step 5: Log and audit every agent action
Every service call should be logged with: the agent ID, the user ID it is acting on behalf of, the capability used, the timestamp, and the result. This gives you a full audit trail — you can see exactly which agent did what, when, and for whom.
Step 6: Implement revocation
Provide a way to revoke any agent's access instantly. Revocation should:
- Stop the auth server from issuing new tokens for that agent
- Invalidate existing tokens (via token introspection or a denylist)
- Be scoped to one agent — revoking agent A does not affect agent B
What This Means for You
If you are using AI agents for your work or small business, the practical takeaway is this: stop giving agents your credentials. Instead:
- Use agent auth protocols (or at minimum, separate OAuth tokens per agent) so each agent has its own identity
- Grant the minimum capabilities each agent needs — read-only by default, write access only when explicitly approved
- Keep an audit log of what each agent does, so you can trace and revoke if something goes wrong
- If you are building with MCP, look into adding an agent identity layer on top — the Agent Auth Protocol SDK is MIT-licensed and ships with MCP integration
The infrastructure is arriving. The Agent Auth Protocol v1.0 is published with reference implementations, v2.0 is in active design covering capability-scoped grants and host attestation, and the IETF has an active Internet-Draft for the Agent Identity Protocol. The question is not whether agent authentication will become standard — it is whether you will adopt it before an incident forces you to.
If you are organizing your AI work into a proper multi-agent system (see our guide to organizing AI work like an operating system), agent authentication is the security layer that makes that architecture safe to actually deploy. And if you are already thinking about access control for autonomous agents, this is the protocol-level implementation of those principles. For the broader security architecture, our 4-layer defense model for AI agent safety and agentic AI security architecture guide put agent identity in context with the other layers you need. And if you are concerned about the AI security risks every business faces in 2026, agent authentication is one of the three barriers you must clear.
FAQ
Q: What is AI agent authentication?
A: AI agent authentication is the process of giving each AI agent its own verifiable identity — typically an Ed25519 cryptographic key pair and a unique agent ID — so that services can identify, scope, and revoke the agent independently of the human user it is acting on behalf of. This replaces the current model where agents share the user's OAuth credentials.
Q: Why should I not just give my agent my OAuth token?
A: Sharing your OAuth token means the service cannot tell which agent made which request, you cannot scope what the agent is allowed to do beyond what your token already permits, and revoking one problematic agent kills all agents sharing that token. It also means a compromised agent has the same access as you — including destructive actions.
Q: What is the difference between OAuth scopes and agent capabilities?
A: OAuth scopes are broad labels (e.g., "read", "write") that tell the client what it can attempt. Capabilities are fine-grained, server-defined actions with constraints (e.g., "transfer_funds, max $1000, to account X only") that the server enforces regardless of what the agent tries to do. Capabilities are enforced at the infrastructure layer, not in the model's context window.
Q: Does the Agent Auth Protocol replace MCP?
A: No. MCP standardizes how agents connect to tools and data sources. Agent auth protocols add an identity and authorization layer on top. Services can expose capabilities through MCP tools while using agent auth for per-agent identity, scoping, and audit. They are complementary — MCP for tool access, agent auth for identity.
Q: Is agent authentication only for enterprise?
A: No. While the protocols are being driven by enterprise security needs, they are open-source (MIT licensed) and designed for any developer or team running AI agents. If you are a small business using agents to automate email, scheduling, or API calls, the same risks apply — and the same protocols work.
Q: What happened in the Clinejection attack?
A: In February 2026, a prompt injection in a GitHub issue title caused an AI triage bot to execute npm install with a malicious package, compromising approximately 4,000 developer machines. The bot had broad tool access with no per-action authorization. This is exactly the kind of incident that per-agent identity and capability-based authorization would prevent — the server would have rejected the unauthorized tool call at the infrastructure layer.
Discussion
0 comments