JTSTech Services
← All articles

E-commerce · October 7, 2026 · 8 min read

Meta and Sierra want shopping agents to stop borrowing your customers' passwords. Their fix leaves you one question: what does "write access" mean at your store?

On 6 October Sierra and Meta published the Personal Agent Protocol, with Shopify, Stripe and Walmart among the founding partners. It replaces the worst habit of today's shopping agents, signing in with the customer's own password, with something every store already understands: a sign-in screen on your side, and a choice between read-only and write. There is no specification yet and nothing to install. But the protocol hands one decision straight back to you, and most stores have never written it down.

Written by Jeremy Souffir Founder, JTS Tech Services

The short version, and the direct answer if you read nothing else. On 6 October, Sierra and Meta published a proposal called the Personal Agent Protocol: an open standard for how a customer's personal AI agent introduces itself to a business, signs in, and what it is allowed to do once it has. It is built on OAuth, the same mechanism behind every "Sign in with" button you have ever clicked. An agent can visit as a guest and ask about stock or your returns policy. If it needs more, the customer signs in on your side and chooses whether the agent gets read-only or write access. Shopify, Stripe and Walmart are among the founding partners, and a first version of the specification is promised later this month. For a store owner, the important part is not the plumbing. It is that the agent stops carrying your customer's password around, and that the protocol leaves the meaning of "write access" to you. That is the decision worth making now, before the spec arrives and your platform makes it for you.

What was actually announced?

  • A proposal, not a product. Sierra's co-founders published it on 6 October as a joint effort with Meta. The named partners are Genesys, Instinct, Rocket, Shopify, Stripe and Walmart.
  • Three levels of access. A guest session, where the agent can ask the questions any visitor could (is this in stock, what is the returns window). A sign-in, where the customer authenticates and the agent can act within their account. And a connected account that persists. In each case the customer chooses read-only or write, and the business sets what the agent can do.
  • One visit, not three. Sessions carry across channels, so a question asked before sign-in and the order placed after it belong to the same conversation.
  • The business picks the route. An agent can be served through your normal website, through APIs described with MCP or OpenAPI, or by handing off to the business's own agent for conversations such as a warranty claim.
  • Explicitly not done yet: more detailed permissions, push notifications for things like order updates, and payments. The payments extension is described as letting an agent buy without the card details being shared, but it is listed as future work.
  • Timeline: a v0.1 specification later in October, then design workshops and a reference implementation. There is no published spec, licence or governing body today, so nobody can tell you exactly what it will look like on the wire. Neither can we, and we have not pretended to.

Whose proposal this is, and who is missing

Read the partner list with the backstory in mind. Meta launched its Muse agent on 8 September, and on 20 to 21 September Amazon began blocking it, objecting that it did not identify itself and that it signed in with customers' stored passwords. We covered that episode at the time. A standard in which agents identify themselves and sign in properly is, among other things, Meta's answer to Amazon. That does not make it wrong. It does mean the most motivated author has the most to gain. Also absent: OpenAI, Anthropic, Google and Amazon, whose agents and shoppers make up much of the traffic. Sierra's Bret Taylor told reporters the current situation "is kind of chaos" until a standard exists, and he is right about the chaos. Whether this becomes the standard is a separate question that nobody can answer in October.

Why does a sign-in screen change anything?

Because of what it replaces. Today, an agent that needs to check an order or reorder something on your store does it the only way available: it signs in with the customer's email and password, from a cloud computer you have never seen, and clicks through your account pages. As we wrote in September, that is almost exactly what an account takeover looks like to your fraud rules. Either they block your real customer or they learn to wave through anything that looks like an agent, including an attacker.

An OAuth-style sign-in turns that around. The customer signs in on your page, sees what the agent is asking for, and approves it. The agent receives a token scoped to what was approved, not a password that unlocks everything. You can see which agent holds which token, and the customer can revoke it without changing their password. This is the same pattern your store already relies on when it connects to an accounting app or an email platform. Applied to shoppers' agents, it means you can tell a customer's assistant apart from someone holding a stolen password, because the assistant came in through a door you built and the thief did not.

Two ways into the same customer account. On the left, an agent signed in with the customer's password reaches every room at once, unannounced. On the right, it stops at a gate the store controls, the customer approves it there, and its connection reaches only the rooms they agreed to.
Two ways into the same customer account. On the left, an agent signed in with the customer's password reaches every room at once, unannounced. On the right, it stops at a gate the store controls, the customer approves it there, and its connection reaches only the rooms they agreed to.

So what does "write access" mean at your store?

This is the part the protocol leaves to you, and it is bigger than it sounds. In version one the choice is coarse: read-only or write. Finer permissions are on the future list. So when a customer clicks "allow write access" for their agent, something on your side has to decide what that unlocks. Does write mean adding to a cart? Placing an order on a saved card? Starting a return? Changing the delivery address on an order that has not shipped? Redeeming loyalty points? Updating the email on the account?

Those are not the same risk, and a single bit cannot tell them apart. Placing a repeat order to the address on file is ordinary service. Changing the email on the account is the first thing an account takeover does. If your platform implements the protocol with one generous default for "write", that default becomes your policy, the way your fraud tool's defaults became your policy for password-sharing agents. The difference this time is that you can see the question coming.

There is a money side too. A survey of merchants by PYMNTS, reported by FinTech Weekly, found that more than nine in ten think the AI provider should carry the loss when an agent buys the wrong thing, and fewer than a third are willing to open their full range to agents. The AI companies have not offered to carry anything, and the protocol's payments extension is not written yet. Until it is, who pays when an agent with write access orders the wrong size is settled by your returns policy and your terms, not by the standard.

The three levels the proposal describes, drawn as nested rings around a store. The outer ring is open to any guest agent. The middle ring needs the customer's sign-in. The inner ring is write access, and what sits inside it, a cart, an order, an address, a stored balance, is the list each store has to draw for itself.
The three levels the proposal describes, drawn as nested rings around a store. The outer ring is open to any guest agent. The middle ring needs the customer's sign-in. The inner ring is write access, and what sits inside it, a cart, an order, an address, a stored balance, is the list each store has to draw for itself.

The two conclusions that both get this wrong

Wait until the protocol war is over

There are now at least four efforts touching how agents deal with stores: OpenAI's Agentic Commerce Protocol, Google's Universal Commerce Protocol, Visa's Trusted Agent Protocol, and this one. Shopify and Stripe sit in more than one camp. It is tempting to treat that as a reason to do nothing. It is half right: do not build against any of them yourself this year. But the decisions underneath them are the same in every camp. What can an anonymous agent learn from you, what can a signed-in one do, and which actions need the human back in the loop. Those answers carry over whichever standard wins, and they are the slow part.

Shopify is a partner, so it is handled

If you are on Shopify, the platform will very probably do the engineering, and that is genuinely good news: you will not be writing an OAuth server. But a platform implementation has to ship with defaults that suit the median store, and the median store is not yours. Somebody will choose what "write" includes for a store that sells perishables, or made-to-order furniture, or anything with a restocking fee, and if it is not you it will be the default. On WooCommerce, expect plugins rather than a platform switch, which puts even more of the choice in your hands.

What is worth doing before the spec lands?

  • Make the guest tier worth visiting. A guest agent will ask about stock, shipping times, returns windows and whether a product fits a need. If those answers live in a PDF, an image or a pop-up, the agent gets nothing and tells the customer so. Put them in plain text on the pages and in the product data where any visitor can read them.
  • Write your "write" list on one page. List every action a signed-in customer can take on your store and mark each one: fine for an agent with write access, needs the customer to confirm directly, or never via an agent. Orders and carts usually go in the first group. Email, password, address and payment changes and stored balances usually go in the second. Our September post has a longer version of this list.
  • Ask your platform and your support vendor one question. "Are you implementing the Personal Agent Protocol, and will I be able to choose what write access includes?" Shopify, Stripe and the customer service platforms in the partner list are the obvious places to ask. Their answer tells you whether you will be configuring a setting or living with a default.
  • Line up your returns policy with agent orders. Decide now how you treat "my assistant ordered the wrong one", because it will arrive before any payments extension does. One sentence in your policy and one agreed answer for support is enough.
  • Do not build anything custom yet. There is no specification to build against. Anything you write this month against a press release will be rewritten.
  • Keep watching the logs you already have. Sign-ins from cloud networks that head straight for order history are the password-sharing agents this protocol is trying to replace. They are not going away the day a spec is published.

The genuinely encouraging part

Two weeks ago the honest description of a customer's agent at your login page was "indistinguishable from a thief". Today a group that includes the largest store platform, a major payment company and the largest retailer has proposed the fix that security people would have asked for: agents identify themselves, customers grant access on your side, the grant is scoped and revocable, and no one hands over a password. It is early, it is one proposal among several, and the hard parts are deferred. But the direction is right, and it puts the store back in the position of deciding who comes in and what they can touch. The store that has already written down what "write" means will be ready the day its platform flips the switch.

Where we fit

Every version of this protocol, and every competing one, starts in the same place: an agent arrives as a guest and asks your store questions. Whether it gets good answers depends on whether your stock, shipping, returns and product facts are written somewhere a machine can read them, and that is exactly what our AI Shopping Visibility work fixes. We audit how agents actually see your store today, fix the product data and policy pages they rely on, and help you draw the line between what a guest agent can learn, what a signed-in one can do, and what still needs your customer in the loop. When the specification lands and your platform starts asking you to configure it, you will be choosing settings from a plan you already have, not inventing one under deadline.

Sources

← Back to all articles

Keep reading

Security

Apple just changed the one Mac setting that decides what an AI agent can read. On most company laptops, nobody knows who already switched it on.

Security

Two senators want the company running the agent to be liable for what it breaks. The standard they chose is "recklessly", not "intentionally".

E-commerce

Shopify's AI will rebuild your storefront in about twenty minutes. The theme it hands back never receives another update, and you can't download it.

AI Shopping Visibility

A guest agent is about to ask your store about stock, shipping and returns. Will it find the answers?

We audit how AI agents actually see your store, fix the product data and policy pages they rely on, and help you decide what a guest agent can learn, what a signed-in one can do, and what still needs your customer, so you are ready when your platform starts switching agent sign-in on.

See AI Shopping Visibility