What Is the Personal Agent Protocol (PAP), and What Does It Mean for Businesses?

AI agents are increasingly interacting with businesses on behalf of consumers. They’re browsing websites, researching products, accessing accounts, and attempting to complete transactions.

But most business digital interfaces weren’t designed for this.

Most websites and business systems were built around two types of traffic: humans using browsers and applications accessing APIs. AI agents introduce a third category: software acting autonomously on behalf of users.

This creates fundamental questions for how businesses can accept their customer’s agents securely. 

The newly introduced Personal Agent Protocol (PAP) attempts to answer some of these questions.  But understanding what it does — and what it doesn’t do — is essential for businesses evaluating how to support AI agents.

NOTE: PAP is still in its early days, with the current specification at draft 0.1. As the protocol evolves, we should expect changes to its requirements, including some that may not be backward compatible with earlier implementations or this write up.

What Is PAP?

The Personal Agent Protocol (PAP) is an open protocol that allows businesses to cryptographically authenticate AI agents, recognize pseudonymous users, and manage persistent sessions and access permissions.

Rather than requiring every AI platform to build a custom integration with every merchant, PAP establishes a common framework for discovering business capabilities, authenticating agents, establishing sessions, and managing authorized interactions.

For example, imagine a consumer asks their AI assistant:

“Find me a pair of running shoes from a retailer I’ve never shopped with before.”

Using PAP, an agent could discover whether the retailer supports agent interactions, authenticate itself, establish a session, and interact with supported shopping functionality.

If the consumer already has an account, PAP also provides mechanisms for authenticating the customer and obtaining permission to access account-specific functionality.

Importantly, PAP is not itself a payment network, fraud prevention system, or independently verified identity service.

It is primarily an agent authentication, session management, and interoperability protocol.

What Information Does PAP Give a Business?

When an agent connects to a PAP-enabled business, the protocol can provide several useful pieces of information.

1. Agent self identification

PAP provides a cryptographic mechanism for identifying an agent.

The business receives an agent identifier and can validate cryptographic assertions associated with that identity.

This allows the business to distinguish a PAP-authenticated agent from an otherwise unidentified automated request.

However, proving that an agent controls a cryptographic key is not the same as independently verifying who operates that agent.

2. A persistent, pseudonymous user identifier

PAP allows an agent to provide a stable identifier representing the user on whose behalf it is acting.

This identifier is designed to be specific to the business.

For example, a retailer could recognize that the same pseudonymous user has returned across multiple agent sessions, even if that user has never created an account.

However, the identifier does not inherently reveal the consumer’s real name or independently establish that a verified human is behind the interaction.

3. Session information

PAP allows a business to establish an authenticated session associated with an agent and its represented user.

This is an important distinction from simply authenticating individual requests.

A business can recognize a returning agent-user relationship, maintain session state, associate permissions with that session, and manage its lifecycle.

4. Authorization and account access

When a consumer already has an account, PAP can support authentication and delegated access using mechanisms such as OAuth.

This allows a business to determine what an agent is authorized to do on behalf of an existing customer.

For example, an agent might be authorized to retrieve order history or manage a shopping cart without receiving unrestricted access to the customer’s account.

The business still controls which permissions it grants and which actions are available.

What Information Doesn’t PAP Provide?

This is where the distinction between agent authentication and verified identity becomes important.

PAP establishes mechanisms for recognizing self identified agents and managing their interactions, but it does not inherently provide the independently verified identity information businesses often need to make security, fraud, and transaction decisions.

For example, PAP does not automatically provide:

• Verified agent operator identity: The legal entity or organization independently verified as responsible for operating the agent.
• Verified consumer identity: The real-world identity of the person represented by the agent.
• Proof of a real human: Independent assurance that the represented user is a genuine person rather than a synthetic or automated identity.
• Consumer identity attributes: Verified name, date of birth, address, or other identity information.
• Fraud and risk signals: Independent assessments of the agent, operator, or consumer.  Technical signals and fingerprints of end user.
• Payment credentials or payment authorization: The ability to independently authorize and complete a financial transaction.

Most of this information is made available through other protocols or additional integrations. But it is not inherently established by PAP authentication.

Consider a consumer using an AI agent to purchase boots from a retailer they’ve never visited.

The retailer might learn that a particular agent is making the request and that it represents a consistent pseudonymous user.

But the retailer still doesn’t necessarily know who that consumer is, whether their identity has been verified, or whether the transaction satisfies its fraud policies.

PAP can establish that a request belongs to an authenticated agent session. It does not automatically establish the person behind the request is known and trustworthy or that a person is actually behind the request at all.

What Does a Business Need to Implement PAP?

PAP is not simply a switch that most merchants can enable on their existing websites.

A business must support the protocol and connect it to the systems through which agents will interact.

Here’s my take on implementation after spending some time with the documentation and examples.  PAP touches a few core components so there’s few steps to a business integration:

1. Publish a PAP discovery document

The business publishes a standardized discovery file at /.well-known/poppy.json.

This allows compatible agents to discover the business’s PAP capabilities and available interaction methods.

2. Implement agent authentication

The business needs infrastructure to validate agent cryptographic assertions and associated public keys.

This establishes that the connecting agent controls the credentials associated with its presented identity.

3. Establish session management

This is going to be the biggest lift for most businesses today.  The business needs to issue, validate, expire, and revoke these agent sessions.

These sessions associate agent self identity, pseudonymous user identity, and applicable authorization state.

4. Integrate with existing authentication systems

If the business wants agents to access existing customer accounts, it must connect PAP to its customer authentication and authorization infrastructure.

This may involve existing OAuth providers, customer identity systems, and account permissions.

5. Enable agent interactions

The business needs to make functionality available through PAP-supported interfaces.

Depending on its implementation, this could include existing APIs, MCP servers, or interactions with business AI agents.

6. Integrate existing security and commerce infrastructure

Finally, the business needs to ensure that its existing security systems, application logic, and checkout processes recognize and appropriately handle PAP sessions.

For merchants, this can include bot management, fraud prevention, customer authentication, and payment systems.

The effort depends on existing infrastructure and which capabilities the business wants to expose. A hosted PAP implementation could simplify some components, but it would not automatically make every existing website or checkout flow agent-ready.

PAP vs. Web Bot Auth: Where the Overlap Is Strongest

One of the most useful comparisons is between PAP and Web Bot Auth, an approach to cryptographically authenticating automated HTTP traffic.

Both attempt to solve a fundamental problem: how can a business recognize automated traffic that identifies itself as a bot?

Web Bot Auth does this at the HTTP request level.

An agent signs requests using cryptographic credentials, allowing the receiving website or security infrastructure to verify that the requests originate from an entity controlling the corresponding private key.

PAP takes a broader approach.

Rather than focusing exclusively on individual HTTP requests, PAP introduces authenticated sessions, pseudonymous user identifiers, and mechanisms for authorization and interaction.

Both can authenticate an agent without independently verifying the real-world identity of its operator or consumer.

This makes PAP more directly overlapping with Web Bot Auth than with a verified identity framework such as Know Your Agent (KYA).

PAP extends the basic agent authentication concept by providing a framework for ongoing interactions and customer authorization.

What Does Session Management Actually Mean?

Session management is one of PAP’s most important additional capabilities.

Imagine an agent visits a retailer to shop for a consumer.

With request-level authentication, the retailer can verify that each signed HTTP request came from an agent controlling a particular cryptographic key.

But request authentication alone doesn’t define an ongoing relationship between the agent, the consumer, and the retailer.

PAP introduces that relationship through sessions.

For example:

1. An agent connects to a retailer and authenticates itself.
2. The retailer establishes a session associated with the agent and a pseudonymous user identifier.
3. The agent browses products and interacts with the retailer across multiple requests.
4. The retailer can associate subsequent activity with the same session and enforce applicable permissions.
5. If the consumer signs into an existing account, the session can reflect that authenticated relationship.
6. The retailer can expire or revoke the session when appropriate.

This creates continuity across interactions rather than requiring each request to be treated as an isolated event.

It can also support more sophisticated experiences involving customer accounts, ongoing conversations, and multi-step transactions.

However, session management is not identity verification.

A business can maintain a persistent session with an agent representing an unknown consumer or bot. The session may be authenticated, but the consumer can still be anonymous.

That distinction is particularly important for guest checkout and other interactions where the business has no existing customer relationship.

PAP and KYA: Solving Different Problems

While PAP and Web Bot Auth focus on agent authentication, Skyfire’s Know Your Agent (KYA) framework addresses a separate problem:

Who is actually behind the agent, and what verified information can a business use to decide whether to trust it?

KYA enables AI agents to present cryptographically verifiable identity tokens containing information about the agent, its operating platform, and the end user, subject to the verification level and information available.

Unlike a pseudonymous identifier alone, KYA can carry independently verified identity attributes.

For example, a KYA token may provide:

• The verified identity of the agent operator or platform.
• Information identifying the agent.
• Verified consumer identity attributes, where available and authorized.
• The identity verification level associated with those attributes.
• Additional identity and authorization context relevant to the interaction.

Businesses can validate KYA tokens and use the information in their existing access-control, security, and fraud decisioning systems.

This is especially valuable when an agent represents a consumer who has never interacted with the merchant before.

Without a preexisting customer account, the merchant cannot rely on its own customer identity records.

KYA can help bridge that gap by delivering portable, independently verified identity claims.

PAP establishes how the agent interacts with the business. KYA establishes independently verifiable information about who is behind that interaction.

And because KYA can be integrated into existing security infrastructure, merchants may be able to recognize verified agents even without implementing PAP.

The Bigger Picture: Authentication Is Not Identity Verification

As agentic commerce develops, businesses will increasingly need to distinguish three separate capabilities.

Authentication: Can I cryptographically recognize the agent making this request?

Authorization: What is this agent permitted to do on behalf of a particular user?

Verified identity: Who authorized this agent to take this action?  Who is actually operating the agent, who is the consumer it represents, and what independently verified claims support those identities?

Web Bot Auth primarily addresses request authentication.

PAP adds standardized sessions, delegated authorization, and business interaction capabilities.

KYA provides portable verified identity claims that businesses can use to make informed trust and risk decisions.

These capabilities coexist in traditional systems.

In fact, the most effective approach to agentic commerce may involve combining them rather than expecting a single protocol to solve every problem.

For businesses, recognizing that traffic comes from an AI agent is an important first step.

But knowing that an agent exists is not the same as knowing who is behind it.

The next generation of trusted agentic commerce will require both: standardized ways for agents to interact with businesses and independently verifiable identity information that allows businesses to trust those interactions.