On October 6, Sierra and Meta announced a new protocol for agents to interact with services - the Personal Agent Protocol, AKA “Poppy”, alongside dozens of partners such as OpenAI, Visa, Cloudflare, Stripe, Walmart, Shopify, major banks and many more. You can read the draft here.
Poppy defines how a personal AI agent connects to a business, identifies itself, gets permission to access a customer’s account, and completes tasks through the business’s website, APIs, or its own AI agent.
Why is this becoming a problem now?
For years, a common approach was to allow known search crawlers and other useful bots while blocking unwanted scraping, spam, and account attacks. Googlebot read public pages and helped people find the site. It did not sign in to a customer’s account or make purchases.
Consumer agents such as Muse and Instinct are doing much more on businesses: Users are now using them to shop, book, and manage accounts on their behalf. Where no suitable integration exists, an agent may use the customer’s login to operate the website. That can look like an account attack even when the customer requested it.
The business needs to establish whether the customer allowed that access and what they authorized the agent to do. Carrying out sensitive actions requires different permissions. It also needs to know who is responsible if the agent makes an unauthorized change or payment.
Amazon blocked Muse from shopping on its site in September, citing concerns about unauthorized access, agent identification, and customer credentials.
In September it was reported that Resy deactivated his account and canceled his reservations after he asked Instinct to find a table. He said the agent’s log showed roughly 200 requests an hour.
Delta told TechCrunch it had no integration allowing third-party agents to book flights, while Yelp required paid access through licensing. The Verge also covered reports of failed Walmart checkouts despite its partnership with Meta.
So it is very obvious that this trend of agents accessing resources on behalf of users is here to stay, and needs solving. Hence Poppy.
How does Poppy actually work?
Poppy builds on OAuth, the framework that powers most identity solutions applications are using today. Businesses can adapt their existing identity infrastructure to support it.
Suppose you ask your agent:
“Move my flight to tomorrow morning. Ask me before paying extra.”
Poppy works by identifying the agent to the business, and prompting the user for authorization with the right permission. The protocol is essentially a coordination mechanism between four parties: the agent, the user, the identity provider and the business. We won’t get exactly to the technical details but this is the flow from a UI/UX perspective:
1. Find how to connect. Your agent fetches the airline’s poppy.json file from a standard address on its website, such as https://airline.example/.well-known/poppy.json.
2. Show its ID. The agent sends signed identity information the airline can verify. The airline can then give it a guest session to do things such as search flights.
3. You choose what is allowed. You sign in on the airline’s own page and approve what your agent can do, such as viewing your booking without changing it. The airline’s authorization server, which may be run by its identity provider, issues a short-lived session token with those permissions. The airline’s systems must then enforce them.
4. The agent gets the task done. It can use a direct software connection, the airline’s support agent, or its website. The same permissions apply across all three.
Your agent can now access your booking, but you asked it to check before paying extra. If the new flight costs $80 more, Poppy’s optional Operations extension lets the airline propose that exact change and wait for confirmation. The agent asks you to approve it, then confirms with the airline. The airline can verify which agent sent that confirmation, but it still trusts the agent to report your approval accurately.
Why identity is also a coordination problem
Even when a business wants to allow an agent, its security systems may still block it.
An agent can be blocked in three places:
At the edge. The CDN or web application firewall can block or challenge traffic before it reaches the company’s application.
At the endpoints. Login, search, booking, and checkout APIs may apply their own authentication, rate limits, and fraud checks.
On the page. Browser checks, JavaScript challenges, and CAPTCHA can interrupt the agent while it uses the website.
These controls can come from three different vendors, each with its own rules and configuration. Recognizing an approved agent in one system does not automatically tell the others how to handle it.
If the airline’s CDN lets your agent in but its API security service rejects the booking request, the agent still cannot change your flight. The same is true if the agent gets through those checks but is stopped by a challenge on the page.
Implementing Poppy means coordinating the company’s security vendors and integrators so that approved agents can complete permitted actions across all three layers.
Poppy vs. other identity protocols
There are many agent identity protocols and attempts out there. Some examples:
Cloudflare Web Bot Auth
We classify these solutions around two questions: (1) who is the agent and the user (identity) (2) what did the user authorized the agent to do (authorization).
Web bot auth by cloudflare only solves 1, who is the agent. Poppy solves both 1+2. So these questions make a good framework for distinguishing between the different protocols.
Another key question is who are the parties involved in Web Bot Auth the main character is the CDN /Edge provider, while in Poppy it revolves more around the identity provider as it is entered around the OAuth protocol..
That addresses agent authentication, but customer authorization is a separate question. Web Bot Auth covers crawlers and personal agents alike; it leaves customer sign-in and delegated permissions outside its scope. Poppy is organized around a personal agent working for a customer. It brings identity, sign-in, account permissions, discovery, and access through websites, APIs, and company agents into one protocol.
Will anyone actually adopt it?
We think Poppy has a significant chance because Meta, OpenAI, and Instinct are involved alongside businesses and infrastructure providers. Agents have little reason to identify themselves if doing so gets them blocked. With developers from both sides involved, businesses can agree to offer reliable access to agents that identify themselves and respect customer permissions. We expect that access to come with conditions and sometimes a price, while businesses keep deciding which agents and actions to allow. Adoption will depend on whether a customer’s agent can actually complete the booking, purchase, or account change.