A standards project was announced, not a finished specification

On October 6, 2026, Meta and Sierra announced that they are developing Personal Agent Protocol with industry partners. Its goal is to give personal AI agents a consistent way to work with companies and let companies see that an agent is acting, whom it represents and which operations it may perform. This is a development announcement: the version 0.1 text has not been published. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026]

Under the described design, an agent first discovers available capabilities on a company website and begins a session for the user. Guest access could be enough to check inventory or a return policy. Account tasks would require the customer to sign in on the company page or use previously configured credentials and choose read-only or write authority. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026]

The session is intended to use OAuth and persist across a conventional website, APIs and the company’s conversational agent. Sierra plans to publish version 0.1 later in October, run design workshops and later release a reference implementation. Fine-grained permissions, notifications and payments are possible extensions, not available features. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026] [2 · IETF RFC 6749 · OAuth 2.0 Authorization Framework]

What would change for an online merchant

The project aims to replace opaque browser automation with explicit delegation. Instead of an agent clicking the same controls as a person, a merchant could declare supported channels and distinguish catalogue browsing from account actions. That creates a basis for controlled work on orders, returns and service, but it does not yet guarantee interoperability. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026]

A simple read-versus-write split is too broad for a working store. Authority should be separated by operation: view orders, build a basket, change an address, cancel an unshipped order, open a return or confirm a purchase. Current OAuth best practice calls for the minimum privileges required and tokens restricted to particular resources and actions. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026] [3 · IETF RFC 9700 · current OAuth 2.0 security best practice]

A continuous session across a site, API and company agent may preserve service context, but it also broadens the error surface. Merchants will need one audit trail showing who granted authority, to which agent, for how long, what changed and how the action can be reversed. The announcement does not yet define that audit format or dispute process. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026] [3 · IETF RFC 9700 · current OAuth 2.0 security best practice]

How to prepare a pilot without exposing live orders too early

The safest first step is a read-only sandbox: inventory, delivery status and return rules without personal data or order changes. Write access should use separate grants, short lifetimes, immediate revocation and renewed confirmation for money, addresses, cancellation and returns. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026] [3 · IETF RFC 9700 · current OAuth 2.0 security best practice]

A short-lived token alone is insufficient. OAuth guidance recommends binding tokens to the sender, restricting them to a particular server and preventing replay. In an open agent ecosystem, client authentication, redirect protection and keeping the customer’s password away from the agent are especially important. [2 · IETF RFC 6749 · OAuth 2.0 Authorization Framework] [3 · IETF RFC 9700 · current OAuth 2.0 security best practice]

A pilot should measure task completion without human help, erroneous changes, cancellations, support contacts, revocation time and attempts to exceed the authorized scope—not merely agent-session volume. Until version 0.1 is published, integration should remain an observation or prototype exercise rather than production order access for unknown agents. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026] [3 · IETF RFC 9700 · current OAuth 2.0 security best practice]

Expert commentary

The project’s central value is not agent intelligence but the boundary of the relationship between shopper and merchant. When software acts for a person, the business must separate the customer’s intent from the model’s own decision. The proposal tries to make representation explicit: an agent states whom it represents and the company controls permitted actions. For now this is architectural intent because version 0.1 is still pending. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026]

OAuth is a sensible foundation. It already separates resource owner, client, authorization server and protected resource and permits tokens narrower than the original grant. Yet OAuth alone does not deliver interoperability. Its base specification warns that many optional components lead to divergent implementations, so the new protocol must prescribe registration, discovery and the meanings of permissions. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026] [2 · IETF RFC 6749 · OAuth 2.0 Authorization Framework]

Least privilege will determine whether the design works for commerce. “Write” must not cover adding to a basket, changing an address and confirming payment in the same way. The first error is cheaply reversible, the second risks misdelivery and the third becomes a financial dispute. Current OAuth guidance calls for tokens restricted to specific resources and actions; the future specification must turn that requirement into a shopper-readable interface. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026] [3 · IETF RFC 9700 · current OAuth 2.0 security best practice]

Competitive impact will depend on openness in implementation, not branding. Large platforms can add discovery and permission flows sooner; smaller merchants will probably receive support through commerce platforms and payment providers. Public conformance tests and reference code could reduce one-off integration costs. Divergent profiles would instead create another family of incompatible connectors. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026] [2 · IETF RFC 6749 · OAuth 2.0 Authorization Framework]

Customer relationships require a verifiable delegation trail: what the person requested, what the agent selected, which grant the merchant checked and how the outcome can be reversed. This matters especially for returns and post-purchase service, where context changes after checkout. The announcement promises session continuity across channels but does not specify the audit record, error liability or correction process. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026] [3 · IETF RFC 9700 · current OAuth 2.0 security best practice]

The proposal becomes testable after version 0.1 and the reference implementation arrive. Observable measures include independent compatible implementations, tasks completed without manual takeover, scope errors, revocation speed, token incidents and successful challenge of a wrong action. Payments cannot be treated as launched; they are only a possible extension. Until then, Personal Agent Protocol is a promising infrastructure proposal, not an operating industry standard. [1 · Sierra · Personal Agent Protocol announcement · October 6, 2026] [3 · IETF RFC 9700 · current OAuth 2.0 security best practice]

Sources

  1. Sierra · Personal Agent Protocol announcement · October 6, 2026 — Official description of the project, consumer and business roles, interaction channels, OAuth, the timing of version 0.1 and possible future extensions.
  2. IETF RFC 6749 · OAuth 2.0 Authorization Framework — Normative basis for delegated authorization: restricted tokens, scopes and separation among the client, authorization server and resource server.
  3. IETF RFC 9700 · current OAuth 2.0 security best practice — Current security practice for dynamic OAuth deployments, including least privilege, audience restriction and protection against token replay.