Meta Partners with Sierra to Launch PAP, Setting Rules for AI Agents

Meta and AI customer-service company Sierra recently joined Shopify, Stripe, Walmart, Genesys, Instinct, and Rocket to launch the Personal Agent Protocol (PAP), aiming to establish a common set of rules for personal AI agents accessing business services.

On the surface, this is the release of a protocol. In practice, it addresses the questions of identity and permissions that arise when agents interact with commercial services: When a business sees an agent accessing its website, how can it verify whom the agent represents? Has the user authorized it only to look up information, or also to place orders and modify them? And how can a business limit what an agent can do and keep track of what it has done?

PAP is still at an early stage. According to Sierra and related reports, version 0.1 is planned for release in late October 2026. For now, it is more accurate to say that several prominent technology and business companies have jointly proposed a direction. PAP is still some way from becoming a widely adopted, validated industry standard.

Why We Need a Set of “Rules of the Road” for Agents

Until now, business websites have primarily served two kinds of visitors: human users and automated programs managed by the businesses themselves. Personal agents blur that boundary. They act on user instructions but may browse products, look up orders, request returns, or even make purchases on the user’s behalf in the background. When a website receives a request, it may not be able to tell whether it came from an agent authorized by a user or from an unauthorized crawler or automation script.

Many agents still operate by having software “pretend to be human”: opening webpages, clicking buttons, filling in forms, and then trying to get through logins and verification checks. This approach is fragile; a website redesign can break the workflow, while anti-bot measures can block it. More troubling for businesses, it lacks clear semantics around authorization: the system often cannot say exactly what the user agreed to when they clicked a button.

This is not simply a matter of automation efficiency. If an agent has access to a user’s login session, it may be able to reach personal information, order histories, and payment flows. Businesses do not want unknown scripts accessing their services in bulk, but neither can they treat a user’s blanket authorization of an agent as permission to perform any action. PAP aims to address three basic questions: “Who is the agent, whom is it acting for, and how far can it go?”

PAP’s Core Principle: Users Grant Permissions, Businesses Set Boundaries

Based on the information currently available, PAP builds on established identity and authorization mechanisms such as OAuth. Users can choose what permissions to grant their personal agents; businesses decide which capabilities they are willing to make available to agents and how those capabilities may be used. Neither side’s control replaces the other’s: a user cannot require a business to expose an interface it has not provided, and a business should not treat user authorization as unlimited permission to access all data and perform all actions.

Returns provide a straightforward example. An agent can first check a business’s publicly available return policy as a guest or see whether a particular item is in stock; these actions do not require authorization through the user’s account. To look up the user’s own orders, the agent must access protected account information. Going further—submitting a return request or purchasing a replacement on the user’s behalf—involves write permissions and should entail greater risk controls and authorization requirements.

PAP therefore does not emphasize “letting AI access every service.” Instead, it aims to make access identifiable, restrictable, and easier to track. Users should know what they have authorized; businesses should be able to define what agents can do and review related access activity. The specific granularity of permissions, revocation processes, and audit mechanisms remain subject to the final specification and its implementation; the protocol’s name alone does not mean that all these details have been settled.

Reports also note that businesses can let agents interact with their services through websites, APIs, or the businesses’ own agents. When APIs are used, PAP’s design direction could work alongside existing interface approaches such as MCP and OpenAPI. The key is the division of responsibilities: MCP and OpenAPI primarily help systems describe and call tools or interfaces, while PAP aims to add a layer for identity and governance—who is accessing a service, what the user has authorized, and what the business permits. They are not the same protocol, and adopting PAP does not mean that any agent can automatically call any API.

From “Simulating Human Actions” to “Operating by the Rules”

The difference between the two interaction models can be understood through the example of running an errand at a store. Browser automation is like having an agent follow the user around, looking for the right counter, filling out forms, and clicking confirmation buttons as a person would. A standardized interface is more like a dedicated service desk set up by the business, with clear instructions about what can be looked up, what can be submitted, and which actions require the user’s own confirmation.

The first approach may seem straightforward to deploy, but it is vulnerable to changes in page layouts and security policies. The second is more stable and gives businesses greater control, but it requires them to provide interfaces, define data access, and maintain the integration process. PAP will not automatically make websites “agent-friendly,” nor can a standard eliminate differences among businesses’ systems. It provides a shared interaction framework; whether a business opens its services, and to what extent, remains up to that business.

That is PAP’s practical value: it aims to spare businesses from having to design separate identity and authorization rules for every personal agent, while giving agent developers the opportunity to connect to different merchants in similar ways. If multiple service providers actually adopt the protocol, developers may be able to write fewer fragile scripts that depend on webpage structures and use more formal interfaces with clearly defined permission boundaries. For businesses, being able to identify an agent and its authorized scope should, in theory, offer more control than simply blocking automated access outright.

However, the value of standardization ultimately depends on adoption, not on the length of the participant list. The services people use every day extend well beyond Shopify, Stripe, and Walmart. Businesses also need to consider existing identity systems, risk controls, customer-service workflows, and compliance requirements. As long as key services remain outside the standard, agents may continue switching between official APIs and simulated browsing, leaving developers to maintain both approaches.

The Biggest Challenge Is Not Authentication, but “Who Is Responsible for the Action?”

OAuth is a mature authorization tool, but it does not decide for a business which actions should require secondary confirmation, nor does it automatically resolve losses caused by mistakes, prompt injection, or poor agent decisions. Giving an agent a valid token establishes only that it has some form of access permission; it does not mean every specific action will match the user’s expectations.

Development teams will need to address at least several issues carefully when implementing the protocol:

• Permissions must be sufficiently granular. “Allow access to the account” is too broad. Reading orders, changing an address, initiating a refund, and completing a payment do not carry the same level of risk.
• Authorization must be revocable and time-limited. If a user switches agents, loses a device, or detects suspicious activity, permissions should be withdrawn promptly rather than remaining in place indefinitely.
• High-risk actions need confirmation. Checking inventory and submitting a payment are not equivalent actions; product design cannot rely solely on a single blanket authorization.
• Businesses need auditable records. In the event of a dispute, it should be possible to distinguish the user’s instructions, the agent’s decisions, and the actions performed by the business’s systems.
• An agent’s identity should not be treated as a security endorsement. Verifying which agent is involved does not mean that the agent is trustworthy or that its output is necessarily correct.

This is why businesses will weigh openness against protection with care. Opening APIs can reduce the uncertainty of browser automation, but every additional callable capability creates another entry point that must be maintained, rate-limited, and protected against abuse. In industries involving sensitive data or high-value transactions—such as banking, healthcare, and aviation—authorization and the allocation of responsibility cannot be glossed over in a technical protocol.

PAP Aims to Establish a Common Language, but We Are Still Far from an “Agent Internet”

Another point of interest is the range of participants beyond Meta and Sierra, including companies in payments, retail, and customer service. This mix could bring real commercial workflows—product searches, account access, payments, and customer service—into the protocol’s development from the outset, rather than limiting it to demonstrations of tool use in a lab. Its open design also gives more businesses and agent developers the opportunity to discuss and adopt it.

But this should not be interpreted as meaning that “personal agents can now access services across major businesses.” Public information so far concerns the protocol’s launch and plans for future specifications, not a cross-platform network that has already been broadly deployed. Version 0.1 has yet to be released. Its compatibility details, test implementations, governance model, and approach to disputes among businesses all remain to be validated through future materials.

More importantly, standards do not compete on technical design alone. Businesses will ask whether adoption can generate revenue or reduce customer-service costs. Users will ask whether authorization is transparent and whether anyone can be held accountable when something goes wrong. Agent developers will ask whether implementations are genuinely consistent across businesses or whether they will need to build a separate compatibility layer for every new partner. If any party lacks sufficient incentive, the standard may remain only a proposal.

PAP is therefore worth watching, but for now it is better understood as an industry coordination effort than as the definitive solution to commercializing personal AI agents. It brings identity, user authorization, and business control into a single design framework, and at least identifies the infrastructure gap at the heart of the agent economy: getting AI to perform actions is not difficult; the challenge is enabling it to act on someone’s behalf in a way that is identifiable, limited in scope, and accountable.

Developers do not need to overhaul their existing integrations in the short term just because PAP has been announced. A more practical approach is to design user identity, authorization scope, and action risk separately, and avoid treating “successful login” as equivalent to “permission to do anything.” Once the 0.1 specification is published, developers can assess how it fits with existing OAuth, API, MCP, and OpenAPI implementations, and whether reusable reference implementations are available.

If PAP ultimately enables finer-grained user authorization, more controlled business interfaces, and more auditable agent actions, it could become an important foundation for agents entering consumer services. If participants standardize only the terminology, without aligning on permission semantics and accountability boundaries, it will be just another integration layer that developers must adapt to business by business. In the coming weeks, whether the 0.1 specification can translate its principles into implementable, testable rules will be the first real test of its substance.