Better Agent Auth — Bereket Habtemeskel & Paola Estefania, Better Auth

The Agent Auth protocol addresses critical security vulnerabilities inherent in how autonomous AI agents currently operate, which often involves granting them full user credentials. This approach leads to significant risks, including a lack of fine-grained control, poor traceability, and difficulty in revoking specific access without impacting the entire user account.

The Core Problem: Agents as Extensions, Not Principals

The speaker highlights the analogy of hiring an employee: a new hire isn’t given the CEO’s credentials but their own specific access rights. Similarly, current AI agent practices often make agents act “on behalf of” the user by using the user’s full credentials, rather than treating them as independent actors with limited, defined authority. This practice was common in the early internet era, where security was an afterthought, and is now being replicated with AI.

Agent Auth Protocol: A Paradigm Shift

The Agent Auth protocol proposes treating agents as principals with their own distinct identities and specific authority, rather than merely extensions or proxies of the user. This approach aims to provide robust security, accountability, and manageability for autonomous agents.

Three Pillars of Agent Auth

1. Discovery: Agents need an automatic, standardized way to understand what actions they can perform and what services are available. Today, users often manually configure agent capabilities. The protocol introduces:
   • Well-known Agent Configuration Endpoint: Similar to OIDC (OpenID Connect) discovery, this provides a public, standardized way for agents to learn how to interact with a service (e.g., encryption methods, available endpoints).
   • Directory: Conceptualized as a “phone book” for agents, this central registry lists services and their associated capabilities. For existing services that offer OpenAPI specifications, the protocol includes a mechanism to translate these specs into granular capabilities, bridging the gap until full native integration is achieved.

2. Authorization (Capabilities vs. Scopes): Traditional broad scopes (e.g., “read access”) provide insufficient control. Agent Auth advocates for capabilities, which are highly specific, granular actions an agent is permitted to perform (e.g., “read specific email from last week,” “delete file X from folder Y,” “send an email to Z”).

   • Users explicitly grant or deny these individual capabilities to agents, ensuring fine-grained control. This prevents an agent from sending emails if it was only intended to read them, even if it gains access to the email service.
   • Capabilities can include constraints such as maximum execution time or specific data access parameters.

3. Identity and Traceability: A core innovation is assigning each agent its own unique identity, secured by a private key. This private key is used by the agent to sign tokens for authentication and authorization, making the agent a distinct principal in transactions.

   • Detailed Audit Logs: With individual agent identities, systems can generate comprehensive audit logs that precisely record “which agent (by its ID) performed what action, when, on behalf of which user.” This provides unprecedented visibility into agent activity.
   • Selective Revocation: If an agent misbehaves or its purpose changes, its access can be specifically revoked without affecting the user’s overall permissions or the functionality of other agents. This is analogous to “firing” an employee.
   • Host-Level Policies: Agents often originate from a “host” (e.g., an AI application like Cursor or Claude). The protocol allows for defining and enforcing policies, and revoking access, at the host level, adding another layer of security.

Protocol Implementation and Demonstration

The protocol is structured into three main layers:

• Agent Plugin (Server-Side): A component for service providers to verify agent identities, issue grants, and enforce authorization policies.
• SDK (Client-Side): An SDK, often integrating with an MCP (Multi-Cloud Platform/Auth Client), enables agents to generate private keys, sign requests, and connect to services.
• Directory: The central lookup service that maps user intents to available capabilities, acting as the agent’s “phone book.” The speaker emphasizes that this is a directory, not a proxy, to avoid scalability and data routing issues.

The live demonstration showcased:

• An “Email Reader” agent requesting permission to read emails, which the user approved via a device flow (treating the agent as a device).
• Detailed logs displaying the agent’s ID, user ID, and the capabilities used.
• An attempt by the agent to “send an email” was initially denied, as this capability was not granted by default. Upon explicit user approval, the agent successfully sent the email.
• Crucially, the ability to revoke an agent’s access was shown, after which the agent could no longer perform previously allowed actions.
• Discussion points included balancing security with user experience (avoiding excessive approval prompts) and implementing host- or user-specific policies for default capabilities.

Future Vision and Call to Action

The Agent Auth protocol is an open-source initiative, with active development (e.g., V2 addressing nuances like ephemeral vs. long-lived agents and enterprise-specific policies). The team encourages community contributions and collaboration, aiming to make AI agent interactions secure and manageable for all users, not just enterprises. The core message remains: stop giving agents user credentials; give them specific, auditable authority.

• Tags:
• Autonomous Agents
• AI Security
• Feature
• API Security
• OpenAPI
• Authorization
• Agent Auth Protocol
• Agent Identity
• Capabilities
• Traceability
• Better Auth
• OIDC