Poppy – A Joint Open Protocol Draft by Sierra and Meta

1. What is Poppy

Poppy (Personal Agent Protocol) is an open protocol draft jointly launched by Sierra along with Meta and multiple enterprises, aiming to address the identity verification and authorization issues when personal AI Agents access enterprise services. This protocol establishes a middle-ground solution between the two extremes of "Agent impersonating users" and "enterprises completely blocking agents" through standardized discovery mechanisms, tiered permission control, and an authorization process based on OAuth. Currently, over 35 companies, including Stripe, Shopify, Walmart, Visa, and OpenAI, have participated in its development.

Technical positioning and domain: It belongs to the identity and authorization protocol in the infrastructure layer of AI Agents, built upon existing standards such as OAuth 2.0, JWT, DPoP, OpenAPI, and MCP. Specifically, it addresses the issues of trusted identity declaration, minimal permission granting, and cross-channel session reuse when personal AI Agents act on behalf of users to interact with enterprise services. This protocol fills the gap between the current AI Agent ecosystem's inability to identify agent identities and users' unwillingness to hand over their passwords.

Development background: Initiated by Sierra and Meta, and supported by industry consensus from over 35 companies, including Stripe, Shopify, Walmart, Visa, and OpenAI. The motivation for its development stems from the practical challenges faced when AI Agents are widely deployed — enterprises cannot determine whether the visitor is a real user or an agent program, and users are reluctant to hand over their account credentials to third-party agents. The protocol aims to establish a unified standard through industry collaboration, rather than relying on a single vendor to dictate a closed standard.

Core value: It solves three key problems: first, enterprises can clearly identify the Agent's identity and understand "who is acting on behalf of whom and what they can do"; second, users do not need to share their passwords, only granting minimal, revocable permission tokens; third, a single login allows session reuse across websites, APIs, and enterprise-owned Agents, avoiding repeated authorization. The protocol is open-sourced under the Apache 2.0 license, and enterprises can quickly integrate it using their existing OAuth infrastructure.

Technical features: Built upon mature standards rather than creating a new system from scratch, it utilizes the discovery file /.well-known/poppy.json to achieve standardized Agent access declarations. It offers five adjustable levels of permissions, supports three login modes: direct, device, and mediated, and ensures all operations are fully auditable and revocable. Additionally, it allows for industry-specific custom extensions.

2. Key Features

• Standard Discovery Mechanism: Enterprises declare Agent access methods, login entry points, and available capabilities by publishing a /.well-known/poppy.json file in the root directory of their website. This mechanism draws inspiration from the RFC 8615 Well-Known URI specification, allowing Agents to automatically discover access paths without prior knowledge of the enterprise's system architecture, thereby reducing integration barriers.

• Tiered Authorization System: Authorization is divided into five levels, ranging from completely restricted to fully controlled. Enterprises determine the authorization level, while users decide the scope of access. This design breaks away from the traditional "all or nothing" authorization model. For example, in a banking scenario, a user can grant only the poppy:read permission to allow the Agent to check account balances, while separate authorization for poppy:write is required for transactions such as transfers, enabling fine-grained access control.

• OAuth Secure Login: Users complete the login process directly on the enterprise's official page, and the Agent only receives the minimal session token approved by the user. The protocol is based on the RFC 8414 OAuth 2.0 Authorization Server Metadata specification, supporting three login modes: direct (direct redirect), device (device code), and mediated (agent-mediated). This ensures compatibility with Web, mobile, and pure API scenarios.

• Single Session Cross-Channel Reuse: A single token can be reused across the enterprise website, APIs, and the enterprise's own Agent, ensuring continuous and uninterrupted interaction. This feature eliminates the need for users to repeatedly authorize across different channels, while DPoP (Demonstrating Proof of Possession) binds the token to the client key, reducing the risk of token theft.

• Multi-Channel Execution Capability: The protocol supports Agents operating directly on web pages, calling OpenAPI/MCP interfaces, or collaborating with enterprise-built AI Agents to complete tasks. It defines discovery, identity, API, and conversation as four core building blocks, allowing the industry to extend capabilities such as payment, push notifications, and interactive components on top of this foundation, ensuring strong scalability.

• Fully Auditable and Revocable: Enterprises can view the complete operational path of the Agent, and users can随时 check connected Agents and disconnect them with a single click in their account settings. All requests are bound to verified client_id, user ID, and scope, forming a complete audit trail that meets enterprise compliance and security requirements.

• Built on Existing Standards: The protocol is constructed on top of OAuth 2.0, JWT, DPoP, OpenAPI, and MCP. Most existing enterprise authorization servers can be directly adapted for integration without requiring a complete rebuild. The protocol follows the "controls over policies" principle, offering options rather than enforcing mandatory rules, allowing enterprises to independently decide on anonymous/logged-in requirements, which Agents are allowed to access, and which channels are open.

• Privacy Protection Design: Before a user logs in, the enterprise can only see a stable ID that does not contain personal information. The same user will have different IDs across different enterprises. This design enables enterprises to identify returning customers without allowing cross-site user tracking, providing personalized services while safeguarding user privacy.

3. How to Use

The Poppy protocol involves three types of participants, each with different usage methods:

1. End User Side: Users do not need to install any additional components and can directly issue tasks to the AI Agent. When a task requires access to a corporate account, users are directed to the official corporate page to complete the login themselves, then check the permissions scope granted to the Agent before proceeding. Users can view connected agents at any time in their account settings and disconnect authorization with a single click. The entire process is transparent and controllable for the user.

2. Individual Agent Developer Side: Developers must first publish a metadata document on the client (containing client_id, public key, and callback address) as the Agent's identity credential. Then, they read the enterprise's poppy.json discovery file to understand its login method and available interfaces. When initiating a session, developers must send a signed assertion and DPoP proof to the enterprise's token endpoint to start an anonymous session and obtain a Session Token. When accessing protected resources, developers must initiate one of the three login types—direct, device, or mediated—in accordance with the enterprise's supported method. After user approval, a long-term Account Token is obtained and encrypted for storage. Afterward, the Session Token can be used to call the enterprise API (with DPoP), browse web pages (browser assertion to Cookie), or communicate with the enterprise's own agents, while handling error scenarios such as 429 rate limiting, idempotent retries, and sign_in_required.

3. Enterprise Integration Side: Enterprises must publish a discovery file at /.well-known/poppy.json, declaring the login method, scope of permissions, and available interfaces. They must configure the OAuth server in accordance with RFC 8414 and declare poppy_domains. Enterprises must verify the Agent's signature, DPoP proof, and scope permissions for each request. Enterprises must also perform the same set of permission checks across all channels, including web pages, APIs, enterprise agents, and human customer service. They must provide a compliant authorization page (displaying the Agent's identity and permission description) and a disconnect option in account settings.

Key Configuration Notes: When integrating with the enterprise, the poppy_domains declaration must be consistent with the OAuth server configuration to ensure that the authorization server metadata can be correctly discovered by the Agent. Permission levels should be set based on business risk assessment, and it is recommended to start with read-only permissions and gradually open up write access. Agent developers must ensure the stability of the client_id and public key mapping to avoid identity verification failures during session renewal.

Notes: The protocol is still in draft form, and some details may change as the version evolves. Enterprises should monitor protocol updates and recommend testing in non-production environments first. Agent developers must handle error states such as sign_in_required, and when tokens expire, they should guide users to reauthorize rather than silently retry.

4. Pros and Cons Analysis

5. Comparative Analysis with Similar Tools

Selection Recommendations: If an enterprise needs to address the identity and authorization issues of "AI Agents accessing enterprise services on behalf of users," and already has existing OAuth infrastructure, Poppy is currently the most suitable solution—it enhances the existing standards with Agent identity recognition and tiered authorization capabilities, and has been endorsed by leading enterprises. If the enterprise primarily focuses on "how to enable LLMs to call external tools" without involving user identity proxy scenarios, MCP is a lighter option.

For developers relying on the ChatGPT ecosystem, ChatGPT Actions provides the lowest integration threshold, but is strongly constrained by the platform and cannot be opened to enterprise-owned Agents. Overall, Poppy and MCP are not mutually exclusive; they can work together within the same system—Poppy handles identity and authorization, while MCP handles tool calling, jointly forming a complete Agent enterprise service access solution.

6. Editor's Summary

The emergence of Poppy addresses a long-overlooked key issue in the large-scale deployment of AI Agents: how to establish a trusted identity declaration and authorization mechanism when agents interact with enterprise services on behalf of users. From a technological innovation perspective, the value of this protocol does not lie in inventing a completely new paradigm, but in organically integrating mature standards such as OAuth 2.0, JWT, DPoP, OpenAPI, and MCP, while filling in two critical missing components: agent identity recognition and tiered authorization. This approach of "incremental design based on existing standards" reduces the adoption barriers for enterprises and avoids the resource waste of reinventing the wheel.

From a practical value standpoint, Poppy's "controls over strategies" principle reflects a pragmatic engineering philosophy — the protocol provides options, enterprises decide the level of openness, and users determine the scope of authorization. This flexibility allows it to meet the differentiated needs of various industries, such as e-commerce, finance, and aviation. The design of single-session cross-channel reuse and full-process auditable and revocable authorization strikes a balance between user experience and enterprise compliance.

This protocol is most suitable for three groups of people: first, developers building personal AI Agent products, as Poppy provides a standardized path for enterprise service integration; second, enterprise technology decision-makers who want to open their services to agents but are concerned about security risks, as tiered authorization and audit mechanisms offer a controllable open solution; third, industry observers focused on the evolution of AI Agent infrastructure, as Poppy has the potential to become one of the de facto standards for agent-enterprise service interactions.

It should be noted that the protocol is still in the draft phase, and its final form will depend on the real-world deployment feedback from participating companies and community contributions. Whether Poppy can truly become an industry standard hinges on two key factors: first, whether more companies are willing to deploy and validate it in real business scenarios, and second, whether the protocol's governance mechanism can remain open and neutral, avoiding dominance by a single large company. With the current participation of over 35 companies, Poppy already has a solid starting foundation, and its development trajectory is worth continuous attention.

7. Application Scenarios

• E-commerce Returns and Exchanges: When a user tells the Agent, "Return the jacket," the Agent queries the return policy as a guest. After the user logs in and authorizes, the Agent automatically completes the return or exchange process. This scenario fully utilizes Poppy's tiered authorization and single-session reuse features, allowing users to complete the entire process—from inquiry to execution—without repeatedly logging in.

• Flight Rescheduling: After a flight is canceled, the Agent queries alternative flights through the airline's MCP interface and automatically completes the rescheduling once the user approves. This scenario demonstrates Poppy's multi-channel execution capability—the Agent can invoke APIs to check flight information and perform rescheduling write operations after user authorization, with the entire process being auditable and reversible.

• Mortgage Pre-approval: After user authorization, Meta's Muse Agent collaborates with Rocket's Agent to confirm the price, down payment, and interest rate, issuing a pre-approval letter within minutes. This scenario showcases Poppy's mediated login mode and inter-enterprise Agent collaboration capabilities, enabling multiple Agents to work together on complex financial processes with just a single authorization from the user.

• Banking Financial Services: When the user grants only the poppy:read permission, the Agent can check account balances and statements. For write operations such as transfers, the user must separately grant the poppy:write permission. This scenario highlights the value of Poppy's fine-grained permission control, allowing users to flexibly adjust their authorization scope based on task requirements, balancing convenience with security.

• Warranty and Customer Service Escalation: The Agent engages in dialogue with the enterprise's customer service Agent to handle warranty claims. In complex situations, the Agent automatically escalates to a human agent or initiates a direct conversation between the user and the enterprise specialist. This scenario fully leverages Poppy's inter-enterprise Agent collaboration capabilities, achieving seamless integration between intelligent and human customer service, thereby improving after-sales service efficiency.

8. FAQ

Q: What is the difference between Poppy and the existing OAuth 2.0 authorization mechanism?
A: OAuth 2.0 identifies applications rather than Agents, and typically uses an "all-or-nothing" authorization model. Poppy adds an Agent identity recognition layer on top of OAuth, binding client_id, user ID, and scope to allow enterprises to clearly know "who is acting on behalf of whom and what they can do." It also introduces a five-tier graded permission system and a single-session cross-channel reuse mechanism, addressing the shortcomings of OAuth in AI Agent scenarios.

Q: When using the Poppy protocol, does the user need to provide their password or API key?
A: No. The user always logs in personally on the enterprise's official page, and the agent only receives a token with the minimum approved scope. The token is bound to the client key via DPoP, and users can revoke authorization at any time with a one-click option in their account settings. Throughout the process, the user's password and long-term credentials are never exposed to the agent.

Q: What is the relationship between Poppy and MCP, and will they replace each other?
A: They address different levels of problems. Poppy is responsible for identity recognition and authorization, while MCP standardizes the connection method between LLMs and external tools. They can work together—Poppy confirms "who has permission to do what," while MCP solves "how to call tools." In practical deployment, enterprises can use both protocols simultaneously to build a complete Agent service access solution.

Q: Does an enterprise need to restructure its existing system to adopt Poppy?
A: No. Poppy is built on existing standards such as OAuth 2.0, JWT, DPoP, OpenAPI, and MCP. An enterprise's current authorization server can be directly modified and integrated. The protocol follows a "progressive adoption" principle, allowing enterprises to start with just one of the options—web, API, or self-built agent—and gradually expand, without needing to restructure the entire system at once.

Q: How does Poppy handle cross-site tracking and user privacy issues?
A: The protocol explicitly prohibits cross-site tracking. Before a user logs in, the enterprise can only see a stable ID that does not contain personal information, and the same user will have different IDs across different enterprises—enterprises can identify returning customers, but cannot link a user's behavior across different platforms. All authorization operations are auditable and revocable.

Q: Is Poppy currently an official standard, and can it be used in production environments?
A: Poppy is currently an open protocol draft and has not yet become an official standard. Although more than 35 enterprises have participated in its development, the protocol details may change with version updates. It is recommended that enterprises first validate it in non-production environments and monitor updates to the protocol. Once a stable version is released, they can proceed with large-scale deployment.

9. Project Links

• Project Website: https://personalagentprotocol.org/