TL;DR
- The Personal Agent Protocol (PAP) gives personal agents a standard front door to businesses, whether they end up on a website, an API or a company agent. What sits behind that door is left to each company.
- We've been exploring one design for that open part: the company agent talks and proposes, but holds no credentials. A deterministic gateway decides, and mints a single-use grant bound to the exact input.
- What this does: it caps the damage a manipulated agent can do at what your policy allows.
- What it doesn't do: it doesn't stop the agent from being manipulated into proposing something that policy allows. Policy becomes the security model.
- This is a prototype with no independent review. Below: what it covers, what it doesn't, and four questions we'd like your help with.
Meta and Sierra, with partners including Genesys, Instinct, Rocket, Shopify, Stripe and Walmart, announced the Personal Agent Protocol (PAP), an open standard for how a customer's personal agent talks to a business. As we read it, the principle is: customers decide what access their agent gets, and companies decide what agents can do.
We think PAP gets important things right. It gives businesses a standard, public way to say how agents can reach them, instead of a thousand custom integrations or agents pretending to be humans on a website. It keeps customers in charge of what access their agent gets, and companies in charge of what agents can do. Leaving the back end open is a sensible scope for a first protocol. The questions below are about that open part. We offer them as a complement to the standard, not a criticism of it.
We have been experimenting with agent ecosystems through a project called Lianxi, an independent open-source project (not affiliated with the companies above) that explores agent-to-business communication from the security side. Reading the announcement taught us two things we had missed: a public discovery file, and one session per customer across channels. The question we kept returning to is the one the announcement sensibly leaves open:
Where does the company agent sit, and who holds the keys to the back office?
Three disclosures up front:
- The PAP v0.1 spec had not been published when we wrote this. We're working from the announcement only. Field names below are ours, not the standard's.
- Only Trust Gateway is open source. Other parts run in a private build, so some claims can't be checked by you. Each is labeled: 🟢 working and public, 🟡 working but private, ⚪ not built.
- No independent security review, and no adversarial testing beyond our own. Everything under "what it covers" is design intent.
Two possible wirings behind the front door
The announcement's diagram shows the company agent as one channel beside the website and the APIs, all under the brand's rules.
Extract from the Sierra announcement.
It deliberately doesn't say how the company agent connects to the systems behind it, and PAP is compatible with many wirings.
Model A is one possible wiring: the customer-facing agent is given tools directly, such as a database connector, a payment key or a refund endpoint. An external agent then has a natural-language conversation with an internal agent that can act on real money and data. That is a confused deputy risk, closely related to what the OWASP LLM Top 10 calls excessive agency. Guardrails and system prompts reduce it, but they are probabilistic controls guarding deterministic assets. We don't know how common this wiring is in practice.
Model B is the one we have been experimenting with:
The model we have been experimenting with. Trust Gateway mediates connections from agents (external or company agents), keeping reasoning, which is probabilistic, separate from execution, which is deterministic.
| Layer | Role | Holds back-office credentials? | Status |
|---|---|---|---|
| 1. Front door | Discovery via /.well-known/personal-agent.json. Callers: your agent, Claude via MCP, shopping agents, external A2A agents |
No | 🟢 |
| 2. Company agent | Talks, explains, negotiates over DID-based A2A | No, by design | 🟡 |
| 3. Gateway | Policy engine, WebAuthn step-up, grant minting | No (signs, doesn't execute) | 🟢 |
| 4. Executors | Verify the grant, then act | Only what the grant allows | 🟢 |
| 5. Enterprise systems | Store DB, Stripe, fulfilment | n/a | n/a |
Two lanes: lookups from your own agent, Claude over MCP or a shopping agent go 1 → 3 → 4 → 5 with no LLM on the company side. Only negotiation (disputes, volume discounts) goes through Layer 2. Either way, Layer 3 is the only component that can authorize a mutation. We haven't benchmarked whether skipping Layer 2 for lookups matters at scale; we chose it to keep simple reads deterministic.
What it covers, and what it doesn't
This is the part we think is useful beyond our own project. It's a threat model for the "company agent holds no keys" pattern, based on design intent and not on test results:
| Threat | Covered? | Why |
|---|---|---|
| Injected agent tries to call a refund or DB tool directly | Yes | It has no such tool or credential |
| Injected agent proposes an in-policy but harmful action (say, a refund inside the limit) | No | The gateway sees a valid proposal and approves it |
| Parameters altered between approval and execution | Yes | The grant is bound to a hash of the exact input |
| Grant replayed | Yes, by design | Single-use, short-lived |
| Stolen grant replayed before first use | Depends on executor state | A bound input hash stops tampering, but preventing duplicate execution requires nonce/JTI invalidation at Layer 4. |
| Compromised executor | No | It still holds Layer 5 access, so isolation and least privilege matter |
| Bug or gap in the policy | No | The policy is now the single point of failure |
| Approval fatigue (the human clicks yes) | No | Passkeys prove who approved, not that the approval was wise |
| Company agent lying to the customer's agent | Not addressed | The model protects the merchant, not the consumer's agent |
So the claim is narrow: the worst case becomes "the most policy allows", not "the most a model can be talked into". We expect that to be a smaller and more testable surface, but we haven't tested it, and we don't know yet whether it is small enough.
What a visit looks like
Short version, with the discovery file, since that is the piece closest to PAP. Here is a small shop selling boxes:
- 🟢 The personal agent fetches the discovery file and learns what each capability requires.
- 🟢 As a guest it can read (catalog, returns policy). Writes are refused with a reason it can relay to its user.
- 🟡 Signing in moves it to the account tier through an OAuth2 token. It never sees a password.
- 🟢 Checkout is a step-up action. The agent only proposes it. The customer approves with a passkey on their own device, and the gateway mints a short-lived, single-use, Ed25519-signed grant bound to the exact cart and amount. The executor verifies it and places the order, and no card number passes through the agent.
- 🟡 Order events are relayed to the customer's channel. ⚪ Showing them in the agent's inbox isn't built yet.
{
"protocol_version": "2026-draft-1",
"routes": {
"mcp": { "endpoint": "https://lianxi.io/v1/mcp/sse", "protocol": "sse" },
"b2b_agent": { "endpoint": "https://lianxi.io/a2a", "did": "did:web:lianxi.io:agent:box-shop" },
"web": { "landing": "/", "sitemap": "/sitemap.xml" }
},
"authentication": {
"supported_tiers": ["guest", "account", "step_up"],
"step_up_mechanism": "webauthn_fido2"
},
"capabilities": [
{ "name": "catalog_query", "required_tier": "guest" },
{ "name": "order_lookup", "required_tier": "account" },
{ "name": "zero_credential_checkout", "required_tier": "step_up", "max_single_transaction_eur": 500.00 }
]
}
protocol_version is our own placeholder. The capabilities block is where the two lanes show up (deterministic tools vs. tiered, step-up-protected actions). It is an experiment, not a proposal for the standard.
Open problems
Promise vs. decision. A negotiating agent can promise a discount that policy then refuses, so the customer hears "yes" and later gets "no". One idea we have not built or tested (⚪): before offering anything, Layer 2 asks the gateway for a dry-run evaluation and may only offer terms returned as a signed, time-limited quote. The gap then becomes an expired quote, not a contradicted promise. We don't know where this breaks. Does it just move the problem into quote management?
Who approves company-side commitments? Passkey step-up is clear for consumer actions. When the company agent agrees a volume discount, who holds the passkey: a human operator, an approval queue, nobody?
Step-up thresholds. Prompts suit high-value actions and annoy people for the rest. We don't have a principled way to set the line.
Weight for small merchants. Five layers is real operational cost. Is there a lighter version that keeps the one key property (the conversational agent holds no execution authority)?
We are very interested in your feedback
- Credentials: does your company agent hold direct API keys, or is there an independent policy checkpoint between the model and your APIs? What drove the choice, and what went wrong?
- Protocol vs. implementation: should a standard like PAP say anything about how a company agent connects to the back office, or is that rightly each company's business?
- Step-up: is OAuth delegation enough when agents act autonomously, or does the flow need cryptographic step-up such as WebAuthn?
- Commitments: how would you reconcile a promise made in conversation with a decision made by a policy engine? Does the signed-quote idea hold up?
Disagreement is welcome, especially if you can show a case the threat model table gets wrong.
- 👉 A more detailed article on our blog, with interactive diagrams and the full PAP-to-Lianxi mapping.
- 👉 GitHub: fcn06/trust_gateway, the open-source Rust policy engine, discovery handlers and grant verifiers.
Top comments (0)