Nearly everything written about agent governance over the past two years — including most of what I’ve written here — assumes you own the agent. You deploy it, you issue its credentials, you decide its tools, you write the policy it runs under. The whole discipline is about constraining something inside your own perimeter.
On 6 October, Sierra and Meta announced the Personal Agent Protocol, developed with Genesys, Instinct, Rocket, Shopify, Stripe and Walmart. It addresses the other direction: an agent that belongs to your customer, arriving at your business, wanting to do something on their behalf.
That’s a different problem, and I don’t think most platform teams have a design for it.
What’s actually proposed
Keeping to what the announcement says, because there’s no specification yet.
The protocol defines how personal agents interact with businesses. It’s built on OAuth. The stated principle is that consumers decide what access to give their agents and companies set the parameters for what those agents can do.
An agent can begin as a guest — enough to check product availability or ask about a returns policy. The customer can then sign in, at which point they decide whether the agent gets read-only or write access. The session carries across that transition, so a question asked before signing in and an order changed afterwards are part of the same visit.
Businesses choose how to be reached: through their website, through interfaces built on standards such as MCP and OpenAPI, or through an agent of their own.
A v0.1 spec is due later this month, with design workshops and a reference implementation to follow. Finer-grained permissions, push notifications and payments are named as future extensions.
So: an announcement, a principle, a partner list, and a spec that doesn’t exist yet. Worth taking seriously — Walmart, Shopify and Stripe are not small commitments — and worth reading as a direction rather than a thing you can build against today.
Why the inbound direction is genuinely different
It’s tempting to file this as “another agent protocol” alongside MCP and A2A. I’d resist that, because the trust relationship inverts and almost every assumption inverts with it.
When you run the agent, you know what it is. You issued its identity, you can revoke it, you can inspect its prompt, you can constrain its tools, and if it misbehaves you can turn it off. Every control I’ve argued for — identities rather than API keys, a gateway it must call, an audit trail it can’t edit — depends on that ownership.
An inbound personal agent gives you none of it. You didn’t build it and can’t inspect it. You don’t know its model, its system prompt, or what else is in its context. You cannot revoke it, only refuse it. And critically: it may be acting on instructions it received from somewhere other than your customer, because an agent that browses the open web is carrying whatever that web told it. Prompt injection stops being a problem inside your system and becomes a property of a counterparty you have no visibility into.
What the protocol can give you is a declared identity and a declared intent. Both are assertions by the agent. The OAuth layer makes the customer’s grant verifiable — that’s real, and it’s the load-bearing part. But “this agent says it is checking a returns policy” is a claim, not a constraint, and designing as though it were a constraint is how this goes wrong.
There’s a second-order effect worth naming. Today your fraud and abuse systems treat automation as a negative signal — bot-like timing, headless browsers, scripted patterns. If a meaningful share of legitimate customer traffic becomes agent traffic, that heuristic inverts, and the detection stack has to tell authorised automation from unauthorised automation rather than automation from humans. That’s a much harder discrimination, and nothing in the protocol does it for you.
The questions I’d want the v0.1 spec to answer
Not objections — these are the things that determine whether this is implementable.
What exactly does the customer consent to? “Read-only or write access” is the right starting frame and far too coarse to deploy. Write access to change a delivery address is not write access to cancel an order or redeem a balance. The announcement lists finer-grained permissions as a future extension, which means the first version ships with the easy half and defers the half that decides whether anyone in a regulated industry can turn it on. How scopes are named and who defines them — the business, the protocol, or the agent vendor — is the whole ballgame, and OAuth’s own history suggests this is where interoperability goes to die.
Does the agent’s identity travel with the request? There’s a well-understood answer to “who acted, for whom” and it’s delegation rather than impersonation — the acting party recorded alongside the subject, not collapsed into it. If a personal agent’s actions arrive looking like the customer, every audit log in every downstream system loses the distinction permanently, and no amount of later tooling recovers it. This is the detail I’d read the spec for first.
What happens when the agent is wrong? A customer’s agent cancels the wrong order. Who’s liable — the customer who delegated, the agent vendor whose model misread, or the business that executed a well-formed authorised request? Protocols don’t settle liability, but the protocol decides what evidence exists afterwards, and that largely determines how the argument ends. If the records can’t show what the agent was told and what it declared, the business absorbs it by default.
How does guest mode not become an abuse surface? Unauthenticated, automated, declared-intent traffic is a category your rate limiter has probably never seen. Check stock, check a returns policy — legitimate, and also exactly the shape of inventory scraping and price surveillance with a cooperative header attached. Businesses will need to decide what guest agents may see, and some of them will discover that what their website shows anonymously is more than they’d choose to hand to a competitor’s agent at machine speed.
And which protocol wins? This is not the only proposal in this space. A standard with Walmart, Shopify and Stripe behind it is not a toy, but a partner list before a specification is a statement of intent, and the agent-commerce protocol landscape is unsettled enough that betting an implementation on any single one right now is premature.
What’s worth doing anyway
Here’s the useful part: most of the preparation doesn’t depend on which protocol wins, or on whether any of them do.
Find out whether agent traffic is already reaching you. Not hypothetically — go and look. Something is already browsing your site on a customer’s behalf, and the honest answer for most teams is that their logs cannot distinguish it from a human session or a scraper. You cannot govern a category you can’t yet see, and the measurement is a day of work.
Decide what read-only means for your own surface. If a customer granted read-only access today, could you enforce it? For most APIs the answer is that read-only is a convention about which endpoints people call, not a scope the system enforces. That’s a gap you’ll have to close for any version of this, and closing it has value regardless.
Make your audit records answer “for whom.” If your logs record which client called and not which human the action was for, you are not ready for delegated access from anyone — agent or otherwise. Same argument as always, now with a deadline attached.
Work out which operations you’d never delegate. There will be actions where you want a human, with a session you authenticated, every time. Decide that list deliberately now, while it’s an architecture discussion, rather than reactively after the first incident, when it’ll be set by whoever is loudest.
None of that is speculative. It’s the work that makes you ready for a customer’s agent showing up, which is going to happen on its own schedule whether or not this particular specification is the one that lands.
The shift I’d flag for anyone running a platform: we spent two years learning to constrain the agents inside the building. The next problem is the ones at the door, and the controls don’t transfer, because every one of them assumed we held the keys.
Related: Your agents need identities, not API keys · Token Exchange: Delegation Is Not Impersonation · MCP is the hands, A2A is the handshake
Comments