Sierra Personal Agent Protocol Adds 35 Partners, but Companies Keep Control

Sierra published its Personal Agent Protocol draft with 35 new design partners, turning Poppy from a proposal into a serious standards effort. The Sierra Personal Agent Protocol now has input from OpenAI, Bank of America, Mastercard, PayPal, Visa, Cloudflare, and other major companies.

The announcement matters because personal agents often enter business systems through interfaces designed for people. They browse pages, fill forms, and sometimes use credentials with broad account access. Poppy proposes a middle path where companies recognize agents, users approve permissions, and one session can cross websites, APIs, and company agents.

That middle path also creates the central conflict. Personal agents need broad, consistent access to be useful, while companies want to control identity, permissions, channels, and customer relationships. Sierra has recruited an unusually broad group to negotiate that boundary. It has not yet shown that those companies will deploy the resulting protocol.

Sierra Personal Agent Protocol Adds 35 Design Partners

Poppy has moved from an initial announcement to a public technical draft, but participation still means design input rather than production adoption.

Sierra released the Poppy draft on October 9, 2026. The company also named 35 additional design partners spanning finance, retail, travel, insurance, media, identity, communications, and AI.

The new group includes Adyen, Atomic, Bank of America, BBVA, Chime, Cigna, Cloudflare, Comcast, DIRECTV, ElevenLabs, FOX, Gap Inc., GEICO, and Hertz. It also includes Insurify, Klaviyo, Liberty Mutual, Mastercard, Nordstrom, Notion, Okta, OneSignal, OpenAI, PayPal, Plaid, and SiriusXM.

Synchrony, Target, United Airlines, Venmo, Visa, Wells Fargo, Zapier, Zendesk, and 1Password complete the additional group. These organizations join companies involved in the earlier announcement, including Meta, Genesys, Instinct, NiCE, Rocket, Shopify, Stripe, and Walmart.

The distinction between the original group and the 35 additions is important. Sierra did not announce 35 total participants. It announced 35 more companies after introducing the project with Meta and several business technology partners on October 6.

According to Sierra, the new companies will contribute feedback based on their business requirements. The list brings together organizations that normally occupy different positions in a transaction.

Banks and payment networks manage identity, fraud, authorization, and settlement. Retailers control inventory, checkout, returns, and customer accounts. Identity providers govern authentication. AI companies build the personal agents that would request access.

Their interests overlap, but they are not identical. An agent developer benefits when one integration reaches many companies. A bank benefits when each action remains attributable, limited, and reversible. A retailer wants agent traffic without losing control over service policies or the customer relationship.

That is why the partner list is more than a collection of familiar logos. It gives Sierra access to the parties that must agree on the boundaries between discovery, delegated access, and real-world actions.

However, a design partner is not automatically an implementer. Sierra has not published production usage figures, completed integrations, or transaction volumes for Poppy. The announcement establishes participation in the design process, not operational support across every named company.

Sierra says it will conduct design workshops and publish a reference implementation during the next month. Those deliverables will provide a stronger test than the partner count. Developers need working code, test environments, and stable conformance rules before they can judge implementation costs.

The current release therefore changes the protocol’s credibility, not its maturity. Poppy now has a public specification and a large set of interested companies. It remains Draft 0.1, with major technical and governance decisions still open.

Poppy Makes Permission the Product

Poppy’s main contribution is not another agent messaging format. It is a shared session and permission model for agents acting inside company-controlled systems.

The Draft 0.1 specification defines a personal agent as software acting for one user. It defines a company as the organization allowing that agent to interact with its services.

A participating company publishes a discovery document at /.well-known/poppy.json. That document identifies the organization and lists its authentication options, APIs, website access, company agent, and supported extensions.

The pattern resembles other well-known web discovery mechanisms. Instead of requiring an agent developer to locate separate integration instructions, Poppy gives the agent one predictable starting address.

Discovery is only the first layer. The personal agent opens a session for a specific user and identifies itself to the company. That design lets the company distinguish automated activity from a person using the site directly.

A session can begin without account access. For example, an agent might check whether a product is available or ask about a return policy as a guest. The user signs in when the task requires personal account information or an account change.

Poppy defines direct sign-in, device sign-in, and mediated sign-in. Direct sign-in keeps authentication on the company’s own page. Device sign-in lets the user approve access on another device by following a link and entering a code.

Mediated sign-in allows an agent to send credentials to a company-defined endpoint when the company permits that method. This option offers compatibility, but it also creates one of the draft’s most sensitive security questions.

Once authorized, the agent receives scoped access. The broad poppy:read scope covers viewing account information, while poppy:write covers changes such as exchanges or booking updates. Companies can define additional scopes for narrower activities.

These scopes create a permission ladder between two unsatisfactory extremes. A company does not have to block every agent. A user also does not have to give an agent every capability available through the account.

The session follows the user across supported interfaces. The agent can move among web pages, OpenAPI endpoints, MCP servers, and conversations with a company agent. A pre-sign-in question and a later account change can remain part of one visit.

That continuity matters for both sides. Users avoid repeatedly explaining the same objective. Companies receive a more coherent record of how the session progressed across channels.

Poppy also defines ways to bring people into an agent conversation. Messages state whether an AI or human created them. A personal agent can request a human representative, while the user can enter a direct conversation without reading the agents’ earlier exchange.

Consider a canceled flight. A personal agent could discover an airline’s supported interfaces, start a session, and search for alternatives without account access. The user could then sign in, approve booking access, and confirm a replacement flight.

A retailer could apply a different policy. It might let an agent start a return while blocking changes to saved payment details. The company, not the personal agent, determines which operations each permission unlocks.

This mechanism explains the protocol’s appeal to companies. Poppy does not ask them to surrender their policies to an outside agent. It offers a standard way to expose those policies and enforce them across several technical channels.

Companies, Not Personal Agents, Keep the Leverage

The protocol promises user choice, but its architecture gives participating companies substantial control over which agents enter and what they can accomplish.

Sierra frames Poppy as a compromise between agent access and company oversight. Users choose a personal agent and approve its account permissions. Companies decide which interfaces, sign-in methods, scopes, and actions they support.

That split looks balanced at a high level. Its practical outcome will depend on how companies configure their implementations.

A company can publish only its website, only selected APIs, or a company agent with a limited task range. It can support read access without write access. It can require direct sign-in for sensitive actions and reject agents it does not recognize.

The protocol therefore standardizes negotiation more than universal access. Publishing a Poppy file would not require a company to expose every customer operation. It would tell agents which doors exist and what conditions apply.

This model directly addresses a costly conflict on the current web. Companies frequently try to detect automation because an agent using a human interface can look like abuse. Agent developers then adapt their browsers to remain functional despite those controls.

Neither side gets reliable information from that contest. The company may not know which service operates the agent or which user it represents. The agent may not know whether a failed action reflects policy, authentication, or an interface change.

Poppy replaces some of that ambiguity with explicit identity and policy. A company can recognize the personal agent’s client identity, associate it with one user, and issue tokens limited to approved scopes.

That arrangement should make legitimate agents easier to distinguish from anonymous automation. It does not remove fraud, compromised accounts, prompt injection, or malicious agent developers. It creates more structured evidence for applying security controls.

Users gain clearer choices, but those choices remain bounded by company policy. A person cannot grant an agent a capability the company never exposes. Likewise, one participating company cannot force another to accept its preferred agent.

This is the core tradeoff behind the Sierra Personal Agent Protocol. Consistent discovery and authorization can expand legitimate agent access. The same design also formalizes each company’s right to limit that access.

The balance could encourage adoption among regulated organizations. Bank of America, BBVA, Wells Fargo, Cigna, and several insurers face obligations that make unrestricted automation unrealistic. They need auditability and strong distinctions between reading data and changing an account.

Payment companies have similar incentives. Mastercard, Visa, PayPal, Venmo, Adyen, Plaid, and Synchrony need to know which party initiated an action. They also need controls that survive when an AI interface sits between the customer and the transaction.

For personal agent builders, the compromise is still attractive if it reduces custom integrations. One discovery format and one authorization model can be valuable even when every company exposes different business operations.

The larger risk is fragmentation inside the standard. Companies can define custom scopes and extensions, while each API retains its own schema. Two organizations might both support Poppy yet require very different implementation work.

Poppy can standardize how an agent arrives, identifies itself, and asks for access. It cannot automatically standardize every mortgage application, insurance claim, flight change, or retail return.

That limitation does not make the project irrelevant. It clarifies where the difficult work begins. The protocol can establish a common front door, while industries and individual companies still define what happens inside.

Existing Agent Standards Are Inputs, Not Rivals

Poppy is most credible as an orchestration layer that uses existing standards, not as a replacement for MCP, A2A, OpenAPI, or commerce protocols.

Agent standards now cover several different boundaries. Treating them as one winner-takes-all contest obscures the problem each one addresses.

Anthropic introduced the Model Context Protocol as a standard connection between AI applications and external tools or data. An MCP server can expose capabilities that an AI client discovers and invokes.

Google originally developed the A2A protocol for communication and collaboration between independent agents. A2A focuses on agents exchanging tasks, messages, artifacts, and status information across vendor boundaries.

Poppy addresses a broader user-to-company relationship. It covers company discovery, personal agent identity, user sessions, authorization, web browsing, APIs, company-agent conversations, and human handoffs.

The distinction appears in Poppy’s architecture. A company can list an MCP server as one available API. It can also list an OpenAPI description, provide its normal website, or expose a company agent.

MCP is therefore one route inside a Poppy session. Poppy supplies the surrounding identity, user authorization, and cross-channel continuity that a tool interface alone does not fully define.

A2A has a similar relationship. A company agent and personal agent need a way to communicate, but their conversation is only one part of the visit. The personal agent might also browse a page or call a conventional API.

Commerce standards create another layer. Shopify and Google’s Universal Commerce Protocol focuses on commerce activities such as product discovery, checkout, and order management.

Sierra explicitly describes UCP as complementary. Poppy can establish who the agent represents and what the user authorized. A commerce protocol can then define the domain-specific operations involved in buying or managing an order.

This layered approach is practical because companies already have varied technology stacks. A retailer might expose a UCP commerce workflow, an MCP customer-service server, and normal web pages. Poppy aims to connect those surfaces to one recognized session.

The approach also avoids forcing every business process into natural-language agent conversations. Structured APIs remain more efficient and predictable for many operations. Web access can cover older systems that lack modern APIs.

Sierra says the protocol builds on OAuth, HTTPS, JSON Web Tokens, OpenAPI, and MCP. These choices lower the conceptual barrier for teams familiar with existing web security and API tooling.

Using established components does not guarantee interoperability. The surrounding profile must be precise enough that two independent implementations behave consistently. Ambiguity around token audiences, scope enforcement, retries, and failure states can still produce incompatible systems.

The protocol’s reference implementation will be important for that reason. Developers need more than prose requirements. They need testable examples for agent registration, discovery validation, token exchange, browser sessions, and conversation handoffs.

The same applies to conformance. If every company interprets optional features differently, personal agents will still need organization-specific logic. A useful standard must identify which behaviors are required for baseline compatibility.

Poppy’s broad partner group can help resolve those details. It can also slow agreement because participants represent competing platforms, regulatory environments, and customer relationships.

The best outcome is not one protocol replacing every other protocol. It is a stack where each layer has a clear responsibility. Poppy succeeds if it makes identity, permission, and session continuity predictable across that stack.

The Draft Leaves Hard Security Questions Open

Poppy provides a security structure, but Draft 0.1 does not eliminate the risks created when software can act through a customer’s account.

The specification warns that any part of Draft 0.1 can change before a stable version. That warning matters because authorization errors at this layer can affect purchases, bookings, financial applications, and personal data.

Poppy uses short-lived session tokens and binds requests to agent identity. It also describes proof-of-possession protections, where the requester proves it holds the key associated with a token.

Those controls can reduce token replay and help companies attribute automated activity. Their effectiveness still depends on correct implementations, secure key storage, and consistent validation across every exposed interface.

Cross-channel sessions increase convenience but enlarge the enforcement surface. A company must apply the same account state and permission boundaries across its APIs, browser endpoints, and agent conversations.

A scope enforced on an API but ignored by a web page would create a bypass. A company agent that performs an action outside the session’s permissions would create another.

Mediated sign-in deserves particular scrutiny. Under that model, the personal agent handles credentials before transmitting them to the company. The specification requires agents to protect secret fields and avoid displaying or logging them.

That requirement is useful, but it cannot prove that every agent handles credentials safely. Companies may decide that mediated sign-in creates unacceptable exposure for sensitive accounts.

Direct sign-in offers a cleaner boundary because users authenticate on the company’s own page. Device sign-in can provide a similar separation when the personal agent operates on a different device.

Permission design presents another problem. The broad read and write scopes are simple, but real services contain actions with very different consequences.

Changing a newsletter preference and changing a mailing address are both writes. Returning a jacket and transferring money are also writes. Companies will need narrower custom scopes or step-up approval for high-impact operations.

Custom scopes improve control but threaten interoperability. Agents must understand what each scope means before explaining it to users. Similar actions may receive different names across companies.

User comprehension is equally important. People routinely approve access prompts without examining their details. Adding agents raises the stakes because one approval may support repeated autonomous actions.

A trustworthy interface must explain which agent is requesting access, which account it will use, what it can read, and what it can change. It should also make revocation easy.

The draft supports revocation and describes long-lived account tokens for starting later sessions. That convenience creates a persistent relationship between the user’s account and the personal agent.

Companies and agent providers will need clear records of those relationships. Users should be able to inspect active connections, granted scopes, recent actions, and expiration dates.

Prompt injection remains outside the protocol’s direct control. An agent can receive malicious instructions from a webpage, message, or external document. Valid authentication does not ensure that the agent’s resulting decision matches the user’s intent.

This concern is especially relevant when an agent blends information from several sources. Good personal knowledge management can improve context, but more context also demands stronger boundaries around disclosure and action.

Human confirmation can reduce risk for purchases, bookings, and account changes. Yet requiring confirmation for every small step would undermine the efficiency that personal agents promise.

The protocol therefore needs more than secure token exchange. Implementations need risk-based approval, transaction records, recovery processes, and clear responsibility when an agent makes a costly mistake.

Design partners from banking, payments, identity, insurance, and cloud security can help pressure-test those questions. Their names alone do not answer them.

Independent security review will be another important signal. Public threat models, interoperability tests, and documented failures would provide more evidence than statements about trust or control.

Poppy should be judged by whether its controls remain consistent under adversarial conditions. A successful demonstration is useful. A recoverable failure is often more informative.

Three Signals Will Decide Poppy’s Future

Working code, real company deployments, and independent security testing will determine whether Poppy becomes infrastructure or remains an ambitious draft.

The first signal is Sierra’s promised reference implementation. The company says it plans to publish one after design workshops during the next month.

A useful release should include both sides of the interaction. Developers need a sample personal agent, a participating company service, discovery documents, authentication flows, and tests for scope enforcement.

The implementation should also demonstrate failures. Expired tokens, revoked access, insufficient scopes, duplicate messages, human handoffs, and interrupted streams are normal conditions in production systems.

Clear code and conformance tests would strengthen Sierra’s argument that companies can implement the protocol with familiar tools. A delay or narrowly scripted demo would weaken that claim.

The second signal is adoption by named partners. A public poppy.json file on a partner-controlled domain would carry more weight than another design announcement.

Early deployments do not need to support every action. A retailer could begin with product questions and return status. An airline could expose schedule information before allowing booking changes.

What matters is whether independent personal agents can discover and use those capabilities without a private integration. If access still requires custom contracts and undocumented behavior, the standard has not delivered portability.

OpenAI and Meta are especially important on the personal-agent side. Their participation creates the possibility of broad distribution. Neither name guarantees that a consumer product will support Poppy.

Banks, payment companies, retailers, and travel providers matter on the company side. Their deployment choices will reveal which authentication and permission models survive regulatory and fraud reviews.

The third signal is evidence that the security model works beyond controlled demonstrations. Watch for public threat models, third-party audits, interoperability events, and documented fixes after testing.

A protocol that enables account actions will attract scrutiny. That is healthy. Researchers should be able to test discovery validation, token binding, custom scopes, browser sessions, credential handling, and agent impersonation defenses.

These three signals reinforce one another. Reference code makes testing possible. Real deployments expose operational problems. Independent review identifies weaknesses before they spread across many services.

The partner list gives the Sierra Personal Agent Protocol a strong starting position. It spans the industries most affected when personal agents move from answering questions to completing transactions.

Still, standards succeed through repeated implementation, not announcement momentum. Companies must expose useful capabilities. Agent builders must support the protocol consistently. Users must understand and trust the permissions they grant.

For developers, the immediate action is to inspect the draft and compare its session model with existing authentication architecture. The most useful feedback will address concrete incompatibilities, missing failure states, or unclear security requirements.

Enterprise buyers should ask vendors whether participation means design feedback, a pilot, or a committed deployment. Those terms represent very different levels of support.

Personal-agent users should watch where control actually appears. Can they see active connections, limit actions, review history, and revoke access without navigating several products?

Poppy is attempting to replace an unstable contest between agent blocking and agent disguise with explicit cooperation. That is a worthwhile goal. The next month should show whether Sierra and its partners can turn that goal into code others can safely implement.