Sign in Subscribe
3 min read

PAP Just Launched. What Does It Do That MCP Doesn't?

Share

On October 6, Sierra and Meta announced the Personal Agent Protocol, PAP, with partners including Walmart, Stripe, Shopify and Genesys. The pitch: a customer's AI agent can carry a permissioned session across a website, an API or a business's own agent, instead of starting over every time it changes routes.

But you can't tell what PAP adds until you know what's already there. Anthropic open-sourced Model Context Protocol, MCP, in November 2024. It standardizes how AI applications connect to tools and data, and already has a versioned authorization spec for HTTP transports. So what does PAP do that MCP doesn't already do?

MCP governs the connection - how an agent calls a tool, what it can see, what it's permitted at the protocol level. PAP, as announced, is aimed one layer up - the relationship. Who the agent is acting on behalf of, what that person actually authorized, and what a business is willing to let an agent with that authorization do, regardless of which route the interaction happens over.

Illustrative order-change workflow. PAP proposes a session across routes; guest access, OAuth, permissioning and handoffs already exist.
Illustrative workflow, not a required protocol sequence. The original labels are retained: guest access, OAuth and handoffs already exist outside PAP; customers choose access and businesses set limits. Actions are not MCP-only, and human handoff is an application choice.

What MCP actually owns

A host, the app the agent runs in, manages clients. Each client connects to a server, which can expose tools, resources and prompts. MCP gives those interactions a common structure instead of every integration inventing its own wiring.

MCP is not unsecured plumbing, either. Its optional HTTP authorization framework is based on OAuth 2.1; local STDIO connections handle credentials separately. So "MCP connects, something else has to secure it" is wrong on arrival.

That framework covers access to protected resources, scopes and token validation. What MCP does not define by itself is the whole customer-business workflow across a website, an API and a business agent.

What PAP is proposing (and isn't, yet)

Per Sierra's announcement, an agent can start as a guest, checking availability or a return policy. For account access, the customer signs in and chooses read-only or write access.

The OAuth session is meant to carry across the routes a business offers: its website, APIs using standards such as MCP or OpenAPI, or its own conversational agent. Sierra puts it plainly: "consumers decide what access to give their personal agents, and companies set parameters for what those agents can do."

Sierra plans to publish v0.1 later in October. Detailed permissions, notifications and payments are possible future extensions. For now, this is an announced design, not a published spec we can evaluate in full.

Authenticated doesn't mean allowed to do everything

Authentication is not blanket permission. These are the separate questions I'd ask before letting an agent complete an action:

  • Identity: whose agent is this, acting on whose behalf?
  • Scope: which resources can it access?
  • Capability: can it only read, or can it change something?
  • Approval: does this particular action need a human to confirm it, or is it pre-cleared?
  • Policy: what will the business accept, independent of what the customer wants?
  • Audit: is there a record of what actually happened?

That's my checklist, not PAP's feature list. MCP already handles parts of authorization; PAP proposes a session across business-facing routes. Neither settles every question above.

The connection works. Who owns the rest?

Sierra's MCP Gateway writeup makes the ownership work concrete: three passes to classify customer data, logged controls on sensitive cross-customer access, user identity for interactive work and limited service accounts for scheduled jobs. The team also centralized permissioning, auditing and legal review instead of repeating them for every integration.

Those are engineering and operating decisions, not things a protocol does for you. Someone still owns access revocation, failed handoffs, audit review and testing the whole path. Specs don't tell you who owns the pager.

MCP has a published, versioned spec and an authorization framework. PAP has an announcement and a v0.1 spec still forthcoming. Its relationship questions are worth taking seriously, but the implementation contract isn't settled yet. Read the announcement as a direction to examine, not a finished spec you can build against yet.

-amrita

Sources

Published by:

Amrita Thavrani

Member discussion