Agents should receive their own authority with explicit limits instead of using a person's credentials.
2
Agent Auth combines capability discovery, authorization, and agent identity so services can track and revoke actions.
3
The workshop demonstrates an agent reading and sending email through an MCP connection, with approval requests and activity logs.
Summary
Paola Estefania presents Agent Auth, a protocol co-created with Bereket Habtemeskel for agents that act for a user or organization. She starts with the risk of connecting an agent directly to Gmail, calendars, or other personal accounts, because the agent then acts as if it were the user. Agent Auth gives each agent its own identity and private key, lets services publish capabilities, and lets users grant narrow permissions. A directory helps agents discover available actions, while logs record which agent acted for which user. The live demonstration connects an email-reading agent through MCP, approves read access, reviews its activity, grants permission to send an email, and then revokes the agent. Paola also explains the protocol's server, SDK, MCP, and directory layers, along with plans to address longer-lived agents and enterprise policies in a later draft.
Paola compares an agent to a person hired by a company. An employee receives their own email, credentials, and limited access. They do not receive the CEO's credentials to read company email. She argues that connecting an AI agent with a user's personal token makes the agent pretend to be that user. Agent Auth changes this relationship: the agent gets authority to act for the user within defined limits. The user remains involved, but the agent is no longer hidden behind the user's identity.
Agents currently learn what they can do because a developer connects tools and describes them by hand. Paola proposes a public configuration endpoint and a directory where an agent can find a service, learn how to interact with it, and inspect its available capabilities. She compares the directory to a phone book. In the short term, the protocol can use OpenAPI descriptions and translate service endpoints into capabilities. The directory can also contain capabilities declared manually for workflows that are not exposed through an existing service description.
Paola contrasts broad scopes such as a generic "read" permission with capabilities that describe a more specific action. An agent's intent, such as retrieving email from the previous week, is matched to one or more tools and capabilities. A user can allow reading while refusing deletion or sending. Constraints can also include a maximum execution time and other conditions. The point is to grant access to a particular operation instead of duplicating everything the user can do.
Each agent receives its own identity and private key. It can use the key to sign tokens, allowing a service to distinguish an agent from the user it represents. Logs can then show which agent acted, for which user, and through which host. Paola describes the agent as a principal actor rather than something hiding behind a user's credentials. This identity also gives the user a way to revoke one agent without disconnecting every service or invalidating the user's whole account.
The protocol has directory, SDK, and server pieces
Paola describes three layers around one protocol. The directory matches an agent's intent with available capabilities. The SDK side connects agents through MCP and creates keys for them. The server side verifies the agent, checks the user's policy, and issues grants that are allowed. An initial draft includes an agent plugin for server verification and grants, plus an MCP integration that can connect to tools used by systems such as Claude or Cursor.
The email demo uses approval before granting access
In the live demo, Paola connects an email reader through MCP and asks it to retrieve a recent email. The directory maps that intent to an email-reading capability. The agent uses device flow, appears with an agent name and identity, and requests approval to read email. After approval, the agent completes the action. The interface displays the agent ID, user ID, host, granted capabilities, and result, showing the identity and audit trail that the protocol adds to a normal tool connection.
The demo starts with the agent holding read capabilities only. When Paola asks it to send an email, the system requests an additional approval through client back-channel authorization. Once she approves, the send-email capability appears and the message is sent. She then denies another request to show that the agent cannot proceed without permission. Policies can be assigned to users or hosts, so a trusted host may receive broader access while a newly connected agent receives only the actions it needs.
Paola revokes the active email-reading agent and then tries to use it again. The original connection is rejected. The demo creates another identity because reading is configured as a default capability for that host, so the new agent can still request the safe read action. Sending email continues to require approval. Paola uses this to show that identity, logs, status, and revocation can work together without removing every connection to the user's account.
"So the idea is like everything get list here. So the directory will be like a phone directory for the agent."15:19
Who should watch
You are connecting agents to Gmail, calendars, or other user accounts and want permissions that are narrower than the user's own access.
You are building MCP tools or agent infrastructure and need agents to discover capabilities, identify themselves, and request grants.
Your team needs an audit trail and a way to revoke one long-lived or misbehaving agent without disconnecting the user from every service.
