Poppy, read closely: a builder's notes on the Personal Agent Protocol

In my last piece I looked at what the Personal Agent Protocol, which its authors call Poppy, means for banks, lenders and insurers. This one is for the people who will build with it. I build my own agent systems, in which data stays with its owner, so I read the specification as an engineer would: what does it get right, and where would I not ship it yet?

First, the momentum. Meta and Sierra announced Poppy on 6 October with a handful of partners, including Walmart, Shopify and Stripe. Three days later Sierra published the first draft and added 35 design partners, among them Bank of America, Wells Fargo, Visa, Mastercard, PayPal, Plaid, OpenAI, Okta, 1Password and Cloudflare. The specification site now carries draft 0.2. Design partners give feedback; they have not committed to deploy. But it is rare to see banks, card networks, an identity provider and a password manager sign up to an agent standard in the same week. That alone makes it worth reading properly.

How it works, in one page

A company publishes a small file at /.well-known/poppy.json. It says who the company is, which sign-in methods it offers, and how an agent can reach it: through the website, through its APIs (OpenAPI or MCP), or through the company’s own agent. The personal agent arrives, identifies itself and starts a session, at first as a guest. If the task needs the customer’s account, the customer signs in and grants a scope, read or write, or a narrower one the company defines. The same session then works across the website, the APIs and the company’s agent, so a question asked before sign-in and an order changed afterwards belong to one visit.

It is built on standards engineers already know: OAuth, JSON Web Tokens, HTTPS, OpenAPI and MCP. That is the right instinct. Nobody needs a new identity system.

What it gets right

The agent is identified, not anonymous. Each personal agent has a client_id that is an HTTPS address. It publishes the agent’s metadata and public keys, and the agent proves who it is by signing. A company can keep allowlists and blocklists, and can revoke an agent that misbehaves. Compare that with today, where an agent browsing a website looks like any other visitor.

Stolen tokens are hard to use. Session tokens are bound to the agent’s own key using DPoP, so a token lifted from a log or a network trace is useless without the private key. The specification says they “SHOULD last hours, not days”. The exception is MCP servers that cannot yet check DPoP, which get ordinary bearer tokens; firms should treat that as a reason to prefer the API route for anything sensitive.

Secrets stay out of the model. This is the provision I was most pleased to see. The long-lived account token must never enter the model’s context, and session tokens, private keys and one-time codes should not either. Requests are meant to be signed by code the model cannot read. That is how I build my own systems, and it is the single most important defence against an agent being tricked into leaking access.

It takes prompt injection seriously. The agent must treat everything a company sends as data, not instructions. It must not act at one company because another asked it to, and it must never treat a company’s text as the user’s consent. In the specification’s words, “Only the User decides what the Personal Agent does.”

Domains cannot be spoofed easily. The company’s file is only trusted if its sign-in server confirms the domain, and the agent must show the company’s name and domain before asking for anything. That closes the obvious route for a fake site to collect sign-ins.

Companies can tell agents what is missing. Draft 0.2 adds an optional feedback endpoint where agents report what they could not find or do. For a firm, that is free product research from every agent that visits.

Three things to fix before it touches money

1. Retire mediated sign-in. Alongside the two OAuth routes, the specification defines “Mediated Sign-In”, in which the agent sends the customer’s username and password to the company. The specification is candid: “This is not an OAuth flow.” It adds sensible safeguards: credentials go only to the company’s declared endpoint, and they are discarded after use or kept in a credential store the user chose. But it still means the customer’s password passes through the agent. UK banking spent years moving third parties away from exactly that. A bank, lender or insurer should not offer it, and I would like to see it removed from the core.

2. Two scopes are not a permission model. poppy:read and poppy:write will do for a retailer. In finance, “write” spans a marketing preference and a new payee. Custom scopes let each firm fill the gap, but every firm defining its own vocabulary defeats the point of a standard. A shared extension for regulated industries, with tiers for reversible and irreversible actions and a clear requirement for the customer’s own confirmation on the latter, would make Poppy far easier to adopt safely. The specification already allows extensions; this is the obvious first one.

3. Revocation should be immediate. When a customer disconnects an agent, its account token is revoked. But the specification notes that session tokens already issued may stay valid until they expire, and asks companies to check sign-in status on every request. That is workable, but it should not be optional. A customer who presses “disconnect” expects the agent to stop now, not in a few hours.

I would add a fourth, which is not a technical point: governance. The protocol is led by Meta and Sierra. A standard that banks and card networks will depend on needs a neutral home and a published process for changes before it reaches version 1.0.

A better answer: mandates, not passwords

Fixing those gaps one by one is useful. But there is a cleaner answer, and UK finance already has most of it. Instead of signing an agent in and hoping its permissions are narrow enough, the customer should give it a mandate: authorise it once, on the bank’s own screen and with the bank’s own strong authentication, within limits the customer sets. The agent then acts inside those limits without asking each time, and cannot act outside them.

Three pieces make it work.

Authorise the agent the way open banking authorises a third party. The agent is identified, the customer consents on the firm’s own page, never shares a password, and can see and revoke every agent’s access from one place. Poppy’s direct and device sign-in routes already work like this. Mediated sign-in does not, which is another reason to retire it.

Let both sides set the scope. The company defines what any agent may do with its products. The customer then narrows that for their own agent: which accounts, which actions, which payees, for how long. The agent gets only what both allow. Poppy today lets companies define scopes, but the customer’s only choice is read or write. Customer-side limits are the missing half.

Give the agent a wallet limit, not a card. UK banks already support Variable Recurring Payments: a mandate the customer approves once, with strong authentication, setting a maximum per payment, a maximum per period and an expiry date. Visa and Mastercard are building agent payment credentials with similar spending controls. An agent that pays through a mandate like this never needs card details or a password, and it cannot spend more than the customer allowed.

The wallet limit matters most, because it answers the three hardest questions at once.

• Consent. A payment inside a mandate the customer approved with strong authentication is clearly authorised, even though the customer was not present when the agent made it.
• Damage. If an agent is tricked or compromised, the loss is capped at the mandate.
• Liability. Inside the mandate, the payment is the customer’s decision. Anything outside it is refused, or sent back to the customer to confirm.

Put together, the model is simple to state: the company sets the outer limits; the customer sets tighter ones; payments run through a capped, time-limited mandate; anything irreversible or over the limit needs the customer’s own confirmation; and one dashboard shows and revokes every agent. None of this needs new law. It needs Poppy, open banking and the card schemes to meet in the middle, and a regulated-industry extension to Poppy is the natural place for that to happen.

What I would do as a builder

If I were running engineering at a consumer finance firm, I would publish nothing yet, but I would:

1. Draft our poppy.json internally, so we know which door we would open, which scopes we would offer and which we would refuse.
2. Offer the direct and device sign-in routes only, never mediated sign-in.
3. Map every customer action to a permission tier, and keep payments, payees and personal details behind the customer’s own confirmation.
4. Design agent payments around capped, time-limited mandates, using Variable Recurring Payments or the card schemes’ agent credentials, never stored card details.
5. Check sign-in status on every agent request, so revocation is immediate on our side whatever the standard says.
6. Join the design workshops. Sierra calls the draft “a starting point”, and the firms in the room will shape the regulated-industry extension.

Poppy is a serious piece of work. Its authors have learned from OAuth, from open banking and from agents being tricked by prompt injection. With mediated sign-in removed, scopes set by both company and customer, capped payment mandates and immediate revocation, it could become the way customers’ agents talk to their banks. That is worth helping to get right.

Sources: Sierra: Introducing the Personal Agent Protocol (6 October 2026); Sierra: Poppy draft and design partners (9 October 2026); Personal Agent Protocol specification (draft 0.2); What is poppy.json?