Summary. SuggestAPI runs an experimental PAP guest catalog pilot: signed mandate chains, selective disclosure, and ephemeral sessions for agent catalog search, with no conformance claim.
A shopper asks an assistant for a wine that pairs with braised short ribs. Behind that question, an agent has to search a merchant's catalog. Reading the catalog is the easy half.
The hard half is proving to the merchant that this agent is allowed to ask, and that nothing about the shopper leaks in the process. SuggestAPI now speaks a protocol built for that second half. We've added an opt-in guest catalog pilot for the Principal Agent Protocol, or PAP, an Internet-Draft that defines how a person's authority reaches the software agents acting for them.
Scope first. This is experimental, it does public catalog search and nothing else, and we don't claim full PAP conformance. The discovery document we publish says so in a field that is always false.
An API key doesn't carry authority
An API key answers one question: is this caller someone we know? It says nothing about whose permission the caller is acting on, what they're allowed to touch, or when that permission runs out. For a search endpoint returning public product data, that gap is survivable. For agent-to-agent commerce it isn't.
PAP replaces the shared secret with a mandate: a signed permission slip that names what an agent may do, what it may share, and when the permission expires. [1]
Permissions pass down a chain. A person holds the root key on their own device. An agent acting for them can hand a narrower permission to another agent, but never a broader one. That limit isn't a matter of good behavior. A mandate that tries to widen its parent's scope, or outlive it, is rejected. [1]
PAP establishes a trust model rooted in human principals, defines hierarchical delegation through signed mandates, enforces context minimization through selective disclosure at the protocol level, and provides session ephemerality as a structural guarantee. [1]
Notice what that leaves out: no token economy, no central registry, no trusted third party, no new cryptography. PAP is assembled from building blocks that already exist, which is part of why it's implementable at all.
What PAP actually specifies
| PAP concept | What it means in practice |
|---|---|
| Person (principal) | Holds the root key on their own device and is the ultimate authority over what agents do on their behalf. |
| Mandate | A signed permission slip: what an agent may do, what it may share, and when the permission expires. |
| Permission chain | Permission passes from the person down to each agent, and every step can only narrow the last one. |
| Selective disclosure | An agent shares only the specific details a task requires, not the shopper's full context. |
| Ephemeral sessions | Each session is single-use and discarded at close, so activity can't be linked across sessions. |
| Co-signed receipts | Both sides sign a record of what was shared and what was done. Receipts note which facts were used, never their values. |
| No central registry | No gatekeeper, no token economy, no new cryptography. The signatures carry the trust. |
One design note worth pausing on. PAP doesn't need an AI model. The draft is explicit that a model may help interpret a request or present a result, but must never grant permission, decide what gets shared, or sign a receipt. [1] The protocol sits underneath the model, not inside it. Given how much of this year's agent commerce conversation assumes the model is the authorization layer, that's a deliberate line.
What SuggestAPI shipped
The pilot is a receiving agent. SuggestAPI checks the incoming authority, then answers a public catalog search for one registered tenant. Each tenant is switched on by hand, so no merchant inherits a new protocol surface by accident.
- A receiving agent that runs PAP's six-step handshake over HTTP, pinned to
draft-baur-pap-02. - An independent client that runs the handshake against us, built separately from our own signing code.
- A test suite covering concurrency, tampering, session closure, cross-tenant isolation, size limits, and restart behavior.
- A signed discovery document per tenant, so agents can find the profile and verify it before trusting anything in it.
The pilot is live on a small set of opt-in tenants.
How an agent finds it and searches
Everything starts from one address per tenant: GET /oks/{tenant}/.well-known/pap. That profile carries a signed advertisement, the endpoint to talk to, the limits we publish, and pointers to the website, the API reference, and the hosted catalog.
Two things to flag. The address itself is a SuggestAPI extension rather than something the draft standardizes, and the profile's compliance field is always false. We'd rather publish an accurate negative than a badge that doesn't survive review.
Agents find the profile through our machine-readable documentation, and a merchant can point at its catalog from its own page. Discovery is pull-only: nothing here pushes notifications at anyone.
From there the handshake runs in six steps. The agent presents a signed permission token, exchanges a fresh session key, states what it will share (nothing, for a guest search), runs the search, co-signs a receipt, and closes the session. Public access needs no customer login, but the signatures are verified at every step regardless.
The draft leaves some details unspecified, so we published our choices in the discovery profile instead of assuming them. An implementation that guessed differently would fail against our endpoint. That's the honest cost of building on an unratified draft.
What the pilot does not do
This list is longer than the shipped list, deliberately.
- No customer login and no access to customer accounts. Guest search covers public catalog data only.
- No cart, no checkout, no payment.
- No revocation or renewal guarantees.
- No federation with other PAP deployments.
- No hardware attestation, which is why we refuse any request asking us to promise we won't retain data.
- No alternative network transports.
PAP authority is also separate from our API key. It opens public catalog search and nothing else, and it can't reach customer resources or internal administration.
Privacy and trust
Worth stating plainly, since the whole point of the protocol is sharing less.
- Guest sessions reveal no personal information at all.
- Sessions are single-use and can't be correlated with each other.
- Session keys live in volatile memory and are discarded when a session ends or the service restarts. A restart ends sessions rather than preserving them.
- PAP traffic stays out of shared caches, our request telemetry, merchant attribution, and Convertmax visit forwarding.
Two limits we won't paper over. Running on isolated workers is an engineering boundary, not a hardware guarantee, and stored data may be subject to platform recovery. So this isn't a claim of tamper-proof erasure.
Frequently asked questions about PAP
What is the Principal Agent Protocol?
The Principal Agent Protocol is an Internet-Draft that defines how a person's authority reaches the software agents acting on their behalf. Permission passes down a chain of signed mandates, an agent shares only the details a task requires, and sessions are single-use. It uses no new cryptography and no central registry.
What can an agent do with SuggestAPI today?
Fetch the tenant profile at GET https://agent.suggestapi.com/oks/demo.suggestapi.com/.well-known/pap and run a guest catalog search. Guest sessions share no personal information and are limited to public product search.