What Is AgentPass? Security, OAuth & AI Agent Access

An agent that only writes drafts doesn’t need keys. One that closes tickets, updates a CRM record, or merges code does. That’s really the line between AI tools and agents. And most teams cross it the lazy way. Somebody pastes a password or a long-lived API key into the agent, and everyone moves on.

AgentPass wants to break that habit. Someone approves one specific task, and the app gives the agent narrow access for just that job. Simple idea. The confusing part is the name, because at least four unrelated products use it. When we checked Google’s AI summary in October 2026, it had mashed them into a single answer.

So we’ll untangle the names first. Then we’ll walk through how Clerk’s protocol gets from approval to access, where its protection runs out, and when a pilot is worth your time.

Clerk’s v0.1 specification calls itself an unaudited work in progress and says not to use it in production. Read every security feature below as a design goal, not a promise. Last checked October 17, 2026.

What Is AgentPass?

AgentPass is an open authorization protocol from Clerk. It gives AI agents short-lived, task-specific access to outside services on a user’s behalf, and the agent never touches that user’s long-lived credentials. The draft is MIT-licensed, and the code sits on GitHub.

Pass vs. token

People mix these two up all the time, so let’s get them straight once.

• The pass is a one-time ticket. The approver issues it, and it dies the moment the app redeems it.
• The token (or browser session) is what the app hands back. It follows the app’s normal expiry and revocation rules, so the agent can keep using it until then.

The rest of this article uses both words in exactly that sense.

Four products, one name

Name	Maker	What it does	Status, Oct 2026
AgentPass protocol	Clerk	Open standard for delegated agent authorization	v0.1 draft
Paz.ai (formerly AgentPass.ai)	AgentPass, Inc.	AI shopping visibility; previously hosted MCP servers	Renamed March 2026
HYPR AgentPass	HYPR	Enterprise agent identity and control plane	Design partner program
Community repos	Independent developers	Agent passports, agent email, trust scores	Experimental

These come from four different teams, and none is part of another. If you searched “AgentPass app,” you probably meant the old AgentPass.ai dashboard. “Paz ai AgentPass” points to its rename. Anything about Authorities, scopes, or DNS records is Clerk’s protocol, and that’s what the next few sections cover.

How the AgentPass Protocol Works

Three parties are involved. A Harness gets a pass from an Authority and cashes it in at a Service.

The three roles

• Harness: the environment where an agent plans and takes actions. The spec mentions coding agents like Claude Code and Codex. In principle, a workflow platform such as Lindy’s task automation agents could fill the same seat.
• Authority: the approver. It reviews the task, picks permissions, and issues the pass.
• Service: the app or API the agent wants to use. It never reads a pass on its own; it asks the Authority instead.

The flow, step by step

Clerk’s site lays the flow out in 11 steps. We’ve grouped them into four phases so they’re easier to follow.

Discovery

1. The agent runs into a task that needs some Service.
2. The Harness looks up that Service’s settings in a DNS TXT record at _agentpass-service.{host}.
3. It sends over the email of the user it’s working for.
4. The Service replies with the Authorities it trusts for that email domain.

Approval

5. The Harness picks one and asks for a pass, describing the task in plain language.
6. That Authority checks which scopes the Service offers.
7. It decides what to grant and whether a human needs to sign off. Since this can take a while, the Harness polls until it hears back. Handy for agents running in the background, because nobody has to sit through a browser redirect.

Redemption

8. Out comes a single-use pass.
9. The Harness hands it to the Service.
10. The Service checks it with the issuer, which marks it spent.

Access

11. The Service opens a browser session or returns a bearer token, limited to the approved scopes.

A successful bearer-token redemption looks roughly like this, adapted from the spec’s own examples:

{
  "bearer_token": "sp_tok_a1b2c3...",
  "scope": ["tickets:read", "tickets:comment"],
  "expires_in": 3600
}

Worked example (illustrative, not tested)

Say Alex runs support at example.com and tells an agent to “triage and respond to open support tickets.” The helpdesk offers tickets:read, tickets:comment, and dashboard:view. Alex’s company approves only the first two, and the helpdesk sends back a one-hour token. Alex’s password stays with Alex. Billing settings stay out of reach. You’d use the same pattern for APIs, command-line tools, and MCP servers.

AgentPass Authority Types

Picture the Authority as a referee standing between the agent and the app. The spec allows three kinds.

Type	Run by	Familiar comparison	Fits
Enterprise	A company, for its staff	Enterprise SSO	Central control over employee agents
Federated	A shared provider many apps trust	“Sign in with Google”	People without a company Authority
Service	The app, for its own users	Self-verified email and password	Apps wanting their own approval screen

Who takes precedence

• A company announces its own approver with a DNS TXT record at _agentpass.{domain}. Once that record resolves, participating apps can’t offer federated providers to the company’s users.
• Apps can still use their own Authority for those users, as long as the company leaves allow_service_authorities switched on. It’s on by default.
• Setting the record to none blocks agent delegation for the whole domain, at least in apps that check.
• Apps can only offer federated providers they’ve listed in their own config.

The adoption problem

It sounds great on paper. Add one DNS entry, and IT controls agent access across every app. The catch? That entry does nothing until each app builds discovery, scope, and redemption endpoints, and that’s a big ask. SaaS platforms run thousands of customers on shared hosts. They’ve also poured their discovery work into HTTP metadata documents, like OAuth’s Protected Resource Metadata (RFC 9728), which MCP servers already have to publish. A DNS-based path from one vendor’s draft means building something parallel. It also pulls in a different team, since corporate DNS usually belongs to IT, and app owners rarely get quick write access to it. As of October 2026, we couldn’t find a public list of apps running it in production. Until that changes, a none record may make IT feel safer than it really is.

AgentPass Security Model

The protocol leans on four ideas to keep agents from hoarding reusable access.

Task scoping

The approver sets scopes when it issues the pass. New task, new pass. A Harness can also ask for less than it was granted, and the app only hands over the overlap.

Single-use redemption

Each pass gets consumed atomically. Try replaying one that’s already been used, and it fails.

Holder binding

The Harness makes a throwaway key pair and sends the public half with its request. When it redeems the pass, it signs a short proof with the private half. That way, only the Harness that asked can cash the pass. The spec recommends this but doesn’t require it.

Binding protects the pass, though, not what comes after it. The token the Service hands back is an ordinary bearer token unless that Service decides otherwise, so anyone who lifts it from memory can use it until it expires. The spec leaves token format to each Service and doesn’t require sender-constrained tokens such as DPoP (RFC 9449).

Periodic revalidation

Apps are supposed to keep checking whether a delegation is still active. Not before every single action, though. They can cache a “yes” for a short while, so revocation kicks in when that cache expires, not instantly. After an admin revokes a delegation, the app has to kill the linked sessions and tokens. And if the app can’t reach the approver at all, the spec says it should fail closed.

Harness trust tiers

Tier	Proof of identity	Typical case	Assurance
Attested	The vendor signs for the Harness key	Cloud agents	High
Registered	Key registered with the Authority in advance	Self-hosted enterprise agents	Medium
Unverified	The Harness names itself	Personal projects	Low

An Authority can turn away any tier it doesn’t trust. Just be clear on what “attested” really buys you. A vendor signature proves which software is running. It says nothing about what the model inside will decide to do, so a hijacked but fully attested agent is still a confused deputy carrying valid credentials.

Validation responses list the user and the agent separately. That’s the same thinking behind keeping a separate identity for agents rather than letting them borrow a person’s login. There’s also an optional task attestation, where the Harness signs the task ID and a hash of its description. It records what was submitted. It doesn’t prove the agent stuck to it.

One more note for enterprise buyers: binding uses JSON Web Keys and signed JWTs. If your machine identity runs on mTLS and X.509, or on workload identity like SPIFFE, plan on building a bridge.

What AgentPass Doesn’t Solve, and Mistakes to Avoid

Authorization answers one question: can this agent touch this resource? Whether it should do a particular thing once it’s in is a separate problem.

Gap	Why the protocol alone falls short	Pair it with
Prompt injection	A hijacked agent can misuse scopes it holds legitimately	Tool-call inspection, human sign-off for high-impact actions
Stolen token or compromised runtime	The redeemed token works until it expires or gets revoked	Sender-constrained tokens (DPoP), short lifetimes, runtime isolation
Data leakage inside scope	tickets:read still exposes every ticket it covers	Data-loss controls, output monitoring
Multi-agent workflows	Orchestrators now routinely spawn sub-agents, yet v0.1 has no way to pass a narrower grant down that chain	Separate delegation tracking until the spec catches up
Liability	Scopes limit access but don’t say who’s at fault when an approved action goes wrong	Written approval policies, retained audit logs

Go back to Alex’s helpdesk for a second. An attacker hides instructions inside a ticket. The agent reads them and posts an internal secret in a public comment. Reading and commenting both sit inside the approved scopes, so as far as the protocol can tell, nothing’s wrong. Scopes limit reach. They can’t judge intent.

Mistakes we keep seeing

1. Mixing up the products. Check the vendor and the URL before anyone signs a budget.
2. Relying on a DNS record nobody reads. Find out which of your apps actually implement the protocol.
3. Approving the * scope. It means “everything this user can do,” which kills the whole point of scoping.
4. Caching authorization checks too long. A former employee’s agent keeps working until the cache clears.
5. Writing vague tasks. “Help with tickets” leaves the approver guessing. “Reply to open P2 tickets in the EU queue” lets it grant just enough.

AgentPass vs OAuth, API Keys

AgentPass isn’t out to kill OAuth. It borrows the same parts (scopes, signed JWTs, JSON Web Keys, bearer tokens) and adds a standard way for an agent to ask an outside approver for a grant tied to one task. OAuth can get you equally narrow access. It just leaves the approval design up to you, so your configuration matters more than the name on the box.

Background agents are where things get interesting. A basic OAuth consent flow expects a person sitting in a browser. Agents working overnight usually lean on refresh tokens, or on token exchange (RFC 8693), which lets a service swap a user’s token for a narrower one. Add resource indicators (RFC 8707), and you can pin that token to one API without anyone clicking a consent screen. So task-level narrowing doesn’t strictly need a new protocol. What AgentPass adds is a standard place for an outside party to approve the task, with the Harness polling while that happens.

Factor	Static API key	OAuth 2.0 / 2.1, well configured	AgentPass v0.1
Unit of approval	Whoever holds the key	A client app, per consent	A described task, per request
Narrowing access	Depends on how the key was scoped	Scopes, short-lived tokens, token exchange (RFC 8693), resource indicators (RFC 8707)	Scopes chosen per task, with optional downscoping
Approver	Nobody after setup	The user, or an admin through consent policy	An Authority: user, manager, or policy engine
Replay defense	None built in	DPoP (RFC 9449) or mTLS, as extensions	Pass consumed on first use; holder binding recommended
Discovery	Hard-coded	Server metadata (RFC 8414) and resource metadata (RFC 9728)	DNS TXT records
Revocation	Rotate the key everywhere	Revoke grants or tokens per app	Authority revokes; apps revalidate periodically
Ecosystem	Universal	Mature standard, wide library support	No public SaaS adoption as of Oct 2026

MCP Authorization

MCP lives on a different layer. Its authorization specification runs on OAuth 2.1 so clients can reach protected MCP servers. AgentPass sits above that and decides whether the agent should run this task at all. In theory, a token from an AgentPass flow could front an MCP server, but nobody has published tests showing it working.

Two more standards tend to come up in enterprise reviews. UMA 2.0 lets a resource owner set sharing policies that a separate authorization server enforces, which is close in spirit to AgentPass’s outside approver. SPIFFE hands workloads short-lived cryptographic identities, so it answers “which service is this?” more than “what may this agent do for Alex?”

For production today, tightly scoped, short-lived OAuth is still the safer bet. AgentPass earns a sandbox pilot when an outside approver for each task fixes a problem you already have.

AgentPass.ai and the Paz.ai Rebrand

If you came looking for a product rather than a protocol, this is probably it. AgentPass, Inc. built AgentPass.ai to host secure MCP servers. In March 2026, the company renamed itself Paz.ai and moved into agentic commerce. Other than the name, it has nothing to do with Clerk.

According to its product documentation, the platform put MCP servers between agents and existing APIs. You could import tools from an OpenAPI spec or build them in a visual editor, set authentication per tool, and connect to ChatGPT, Claude, Cursor, or VS Code in a few clicks.

The rebrand announcement says the San Francisco company now helps mid-market and enterprise retailers show up in AI shopping channels like ChatGPT, Google AI Mode, Perplexity, and Claude. Existing integrations carried over.

So what does that mean for you?

• Hosting MCP servers there? Ask about the roadmap before you build anything new on it.
• Running an online store and curious about AI shopping? Paz.ai is now aimed squarely at you.
• Reading reviews? Sites like G2 still mix old AgentPass.ai descriptions with the new name, so check the dates.

HYPR AgentPass and Community Projects

HYPR is best known for passwordless login. It pitches HYPR AgentPass as an enterprise control plane with verifiable agent identity, inline policy, human sign-off on risky actions, and instant revocation. Right now you get in through a three-month design partner program, so confirm availability first. Analyst firm Intellyx describes the kind of control it’s after, like letting an agent draft an email but holding back the send.

A couple of independent developers have used the name too.

• kai-agent-free/AgentPass gives an agent a cryptographic passport, a working email address, and 17 MCP tools.
• romirom11/AgentPass is an installable skill. An agentskill.sh audit on June 4, 2026 scored it 68 out of 100 and flagged 12 issues, mostly calls to outside URLs. It’s a good reminder of how agent skills work and where a skill can overreach.

Treat both as experiments until you’ve read the code.

One more source of confusion. Google’s summary for this keyword talks about X.509 certificates, Ed25519 keys, and trust scores. Most of that comes from related work, such as Raza Sharif’s IETF drafts and his AgentSign project. Clerk’s spec uses JSON Web Keys and signed JWTs.

Which AgentPass Fits Your Situation?

Start with the problem you’re solving. The brand matters less.

Situation	Underlying need	Where to look	Readiness
SaaS app whose users’ agents log in with passwords	Safe, scoped agent sign-in	Clerk’s protocol, Service side	Prototype
CISO worried about unmanaged agents	Central approval and revocation	An Enterprise Authority or HYPR AgentPass	Pilot
APIs you want exposed as MCP tools	Tool hosting and access control	An MCP gateway; confirm AgentPass.ai’s roadmap first	Mature options exist
Online store	Visibility in AI shopping	Paz.ai	In market
Personal agent experiments	Basic agent identity	Community repos, after review	Experimental

Still unsure? Ask yourself three things.

1. Are you building the app, approving access, or building the agent? That’s Service, Authority, or Harness.
2. Does this need to be live this quarter? Then go with OAuth now and come back to AgentPass later.
3. Does the person granting access sit outside the app? If so, an outside approver beats a separate consent screen in every app.

In production, most teams will do better with OAuth 2.1 and PKCE, short-lived scoped tokens, token exchange where agents act for people, and a policy engine like Open Policy Agent or Cedar at the gateway. Keep AgentPass in a sandbox, ideally on internal services where you own both the Harness and the Service. Designing around task descriptions, narrow scopes, and revocable delegations now means a later switch won’t hurt much.

AgentPass Pilot Checklist

Here’s what a sandbox pilot needs, broken down by role.

App builders (Service)

• Publish _agentpass-service.{host} Pointing to an HTTPS configuration URL
• Define granular scopes, like invoices:read instead of billing:*
• Return only the scopes each task actually needs
• Validate every pass through the Authority
• Verify holder proofs whenever a key comes back
• Keep browser initialization links single-use and short-lived
• Log the user, agent, task ID, and Authority on each redemption

IT and security (Authority)

• Choose between a URL and none for _agentpass.{domain}
• Set allow_service_authorities to match your policy
• Decide which Harness trust tiers you’ll accept
• Name the tasks that need human approval, and who approves them
• Turn on DNSSEC
• Rehearse an offboarding revocation from start to finish

Agent builders (Harness)

• Send a fresh holder-binding key with each request
• Write specific task descriptions
• Ask for the smallest scope set that works
• Treat every pass, link, and token as opaque

Agent Authorization Trends in 2026

AgentPass has plenty of competition. Most of its rivals are also individual IETF drafts, not adopted standards. The OpenA2A Agent Authorization Protocol, the Agent Passport System, a July 2026 counter-sign draft for human countersignatures, and Raza Sharif’s agent certificate work all chase similar problems. The Agent Auth Protocol treats every agent as its own principal and finds services through a /.well-known/agent-configuration file rather than DNS. And mature OAuth extensions like token exchange might make a dedicated protocol unnecessary anyway.

A few shifts look likely to stick, whichever spec wins.

1. Vendor signatures matter. AgentPass’s top trust tier needs the agent maker to sign. Whatever format the big agent vendors back will probably spread.
2. Tasks replace apps as the unit of permission. Most new drafts tie access to a described action instead of a standing grant.
3. Delegation chains get urgent. Orchestrator agents already hand work to sub-agents. A spec that can’t pass a narrower grant down that chain will struggle, and v0.1 doesn’t try yet.

Honestly, the hardest part might not be the crypto at all. It’s getting thousands of SaaS vendors to publish scopes, run redemption endpoints, and keep re-checking delegations.

FAQs

Q. What is AgentPass used for?

It lets an AI agent use a third-party app for someone without holding their password or long-lived keys. An approver signs off on each task and issues a one-time pass, and the app swaps it for limited access.

Q. Who created the AgentPass protocol?

Clerk, the authentication company. It’s an MIT-licensed open project, and the draft lives at agentpass.com.

Q. Is AgentPass the same as Paz.ai?

No. Paz.ai is the new name of AgentPass, Inc., which made the AgentPass.ai MCP platform and moved into agentic commerce in March 2026. It’s unrelated to Clerk’s protocol.

Q. Is AgentPass production-ready?

Not as of October 2026. The v0.1 draft says it hasn’t been audited and shouldn’t run in production.

Q. How does AgentPass differ from OAuth?

OAuth can give narrow, short-lived access, but you design the approval flow yourself. AgentPass builds per-task approval by an outside party, one-time passes, and regular re-checks into the protocol. You can run both side by side.

Q. Can AgentPass work with MCP servers?

In principle, yes. It can issue bearer tokens that an MCP server accepts, and MCP’s own authorization runs on OAuth 2.1. Nobody has published tests of the combination yet, though.

Related: OpenHands vs Devin vs Manus: Best AI Agent in 2026

Disclaimer: This AgentPass review is for informational purposes only. We’re not affiliated with Clerk, Paz.ai, or HYPR. Security claims reflect available documentation, not independent audits. Clerk’s v0.1 protocol remains experimental and is not recommended for production use.