Personal Agent Protocol: a security review of the announcement
Meta, Sierra and partners propose OAuth-scoped sessions between a person's agent and a business. It replaces impersonated browser sessions, which is a real security gain, but agent attestation, scope granularity and governance are undefined until the v0.1 spec.
This review is based on the announcement and press coverage. No specification was published at the time of writing; it will be updated when v0.1 ships.
In brief
- PAP standardises discovery, guest sessions, OAuth sign-in with read or write scope, and sessions that carry across channels.
- Security gain: agents stop stuffing credentials into web forms and impersonating browsers.
- Gaps: no described agent attestation, coarse scopes, no published spec, licence or governing body.
- OpenAI, Anthropic and Google are not partners; tool access reuses MCP or OpenAPI.
What was announced
Sierra and Meta, with Genesys, Instinct, Rocket, Shopify, Stripe and Walmart, announced the Personal Agent Protocol (PAP), an open standard for how a person’s AI agent discovers a business, opens a session (guest first, then signed in) and acts with a user-chosen read or write scope. Sessions carry across channels. A v0.1 spec is due this month. OpenAI and Anthropic are not listed as partners.
The flow
PAP covers the session and consent layer between a consumer’s agent and a business. Tool access reuses MCP or OpenAPI, and payments are left to existing commerce protocols (UCP, ACP, Visa TAP).
Security assessment
PAP addresses the problem behind the Amazon and Meta Muse dispute: Amazon blocked Muse partly because it browsed without identifying itself. Replacing impersonated browser sessions with an explicit, OAuth-scoped session the business sanctions is a real improvement. There’s no credential stuffing into web forms, consent happens on the business’s own page, and the business decides what agents may do.
| Property | What the announcement says | Assessment |
|---|---|---|
| User consent | OAuth sign-in on the business’s page | Sound: consent stays with the business and the user |
| Scope | Read-only or write, chosen by the user | Too coarse: “write” covers both updating an address and placing an order |
| Agent identity | Not described | Main gap: a business can’t tell which vendor’s agent it is talking to, or verify it |
| Session portability | Sessions carry across channels | Needs token binding, or a stolen session token works everywhere |
| Tool access | MCP or OpenAPI | Inherits MCP’s auth model, and its implementation hygiene problems |
| Payments | Deferred to UCP, ACP, Visa TAP | Reasonable, but adds a second trust model to review |
| Governance | Not stated | No licence, owner or change process yet |
The announcement says nothing about how an agent proves which person and which vendor it represents. Without that, a business can rate-limit or block agents only by behaviour, which is exactly what PAP was meant to move beyond. Coarse scopes are the second concern: once write access is granted, the protocol as described doesn’t distinguish low-risk from high-risk actions. Action-level scopes are listed as future work.
Where it fits
PAP joins a crowded field: UCP, ACP, Visa TAP and AP2 for commerce, and A2A for agent-to-agent work. Its distinct contribution is the business-sanctioned session. Without OpenAI, Anthropic and Google, its reach for now depends on Meta’s own agents and the partner merchants.
What to do
If you run customer-facing services, agent traffic needs a front door; without one you get scraping and form-filling agents, the behaviour documented in this week’s containment disclosure.
Recommendation (opinion): watch for the v0.1 spec and judge it on two things: agent identity and attestation, and fine-grained, action-level scopes. Meanwhile, expose an OAuth-protected MCP or OpenAPI surface so agents have a sanctioned path into your service.