v0.1 Draft
AgentPass: an open protocol for agent authorization
A Harness obtains an AgentPass from an Authority, then presents it to a Service to redeem a minimally-scoped browser session or bearer token.
What is an Authority?
AgentPass introduces a trusted Authority to approve and scope agent tasks, instead of handling authorization directly between a Harness and a Service. Three types of Authority are supported, each with a different trust model:
Enterprise Authority
An Authority run by an organization for its employees. It enables oversight and control over agent approvals.
Compare to enterprise SSO
Federated Authority
A shared Authority for users not part of an Enterprise Authority. It centralizes agent approvals across many Services.
Compare to “Sign in with Google”
Service Authority
An Authority run by a Service for its own users. It allows the Service to offer a custom agent approval experience.
Compare to self-verified email/password
Why have Authorities?
Authorities make authenticated agents easier to adopt and manage. They enable:
- Centralized approvals: Enterprise and Federated Authorities give users a single place to review and approve agent authorization requests across many Services, instead of requiring them to visit each Service separately.
- Automated signups: Since Enterprise and Federated Authorities are trusted, Services can use the identities they provide to create accounts on demand. This enables new Service adoption from within a Harness, without completing a separate signup flow at each Service.
- Enterprise readiness: Enterprise Authorities provide agent oversight by default. Once a domain publishes its Authority via DNS, Services automatically defer to it—avoiding the per-Service setup typical of enterprise SSO.
Authorize the task, not the Harness
AgentPass issues short-lived, single-use credentials for a single task, so access stays governed by the Authority instead of accumulating inside the Harness.
Task-scoped
Each AgentPass is issued for a single task. The task description and scope are bound at issuance.
Single-use
AgentPasses are consumed atomically on first use. Replay is impossible.
Holder-bound
Cryptographic proof-of-possession ensures only the requesting Harness can redeem an AgentPass.
Continuously validated
Services re-verify authorization throughout the session to check for revocation.
One authorization flow, many access models
AgentPass is interface-agnostic. Once approved, the AgentPass is redeemed at the Service for the access the task requires, either an authenticated browser session or a bearer token for APIs, CLIs, and MCPs.
How it works
- 1A Harness is executing a task that requires authorization from a Service.
- 2The Harness discovers the Service’s AgentPass configuration via DNS.
- 3The Harness provides the email of the user or agent it’s acting on behalf of.
- 4The Service returns a list of trusted Authorities for the provided email domain.
- 5The Harness chooses an Authority and requests an AgentPass scoped to the email and task.
- 6The Authority discovers the available scopes from the Service.
- 7The Authority obtains approval for the task, determining which scopes are granted and whether a human-in-the-loop is required.
- 8The Authority issues a single-use AgentPass to the Harness.
- 9The Harness presents the AgentPass to the Service.
- 10The Service validates the AgentPass with the Authority.
- 11The Service establishes a browser session or bearer token with the approved scopes.
AgentPass is open source and developed by Clerk.