Atlassian's October 13 Price Hike Is the Dual-Billing Test Enterprise SaaS Needed

On October 6, 2026, Sierra and Meta jointly announced the Personal Agent Protocol — an open, OAuth-based standard that lets a personal AI agent authenticate with a business, declare what permissions a customer has granted, and take actions on their behalf without impersonating the user or holding their credentials. Founding business partners include Shopify, Stripe, Walmart, Genesys, Instinct, Rocket, NiCE, and Decagon. On October 9, the design partner group expanded to 35 additional organizations, with OpenAI among them.

The announcement is six days old. The specification — internally nicknamed "Poppy" — is still in draft form. A governance body has not been publicly named. None of that diminishes what the announcement represents: the moment the agentic commerce industry decided that the identity layer — the foundational trust mechanism that lets an AI agent prove it is acting with a real customer's explicit consent — needed an open standard before a dozen proprietary implementations locked in incompatible approaches.

The Personal Agent Protocol is not primarily a technical announcement. It is a distribution strategy announcement. It tells us which companies believe they will benefit from a world where AI agents transact on behalf of users at scale, and which are willing to subordinate their platform control to get there faster.

The Identity Problem Every Agentic Commerce Platform Has Been Ignoring

The core challenge of agentic commerce is trust delegation. When a user authorizes their personal AI assistant — from OpenAI, Anthropic, Apple, Google, or any other provider — to complete a purchase on their behalf, three parties need to verify something.

The business needs to verify that a real customer with an active account has actually authorized the agent to act. The customer needs to verify that the agent is acting within the scope they approved and not acquiring broader permissions. The agent needs a machine-readable way to declare its identity, the customer it represents, and the specific permissions it holds.

Without a shared protocol for this verification, every agentic interaction requires one of three workarounds. The first is credential forwarding: the agent holds the user's actual login credentials and logs in as the user. This is the pattern that screen-scraping automation tools used for 20 years before OAuth existed for humans. It is insecure, creates liability for the agent provider, and breaks the moment a business changes its authentication flow. The second is business-specific APIs: the agent calls a dedicated API endpoint the business built specifically for agents. This works for large platforms that can justify the engineering investment, but creates a fragmented ecosystem where agents need separate integrations for every commerce partner. The third is human-in-the-loop confirmation: the agent drafts the action but requires the user to click to confirm. This reduces the value of the agent to a slightly smarter browser extension rather than an autonomous workflow executor.

The Personal Agent Protocol is the OAuth equivalent for agents — the moment agentic interactions stopped requiring workarounds and started having a shared trust standard. Just as OAuth 2.0 in 2012 ended the era of "give a third-party app your password," PAP is designed to end the era of agents impersonating users or requiring manual confirmation for every authorized action.

What the Personal Agent Protocol Actually Is

According to Sierra's announcement and the analysis from eesel.ai, PAP is built on OAuth and defines three interaction models for a business participating in the protocol.

The business can offer its standard consumer website — the agent navigates it with authentication tokens rather than passwords, using the standard web interface the business already maintains. The business can offer a dedicated agent API — a machine-readable interface optimized for programmatic access, with structured data responses rather than rendered HTML. Or the business can offer its own AI agent — a specialized agent that communicates with the personal agent using A2A (Agent-to-Agent) protocols, handling the interaction at the agent layer rather than the user interface layer.

The customer's role in the protocol is central, not incidental. PAP requires explicit customer authorization for each permission the agent requests. The customer chooses whether the agent has read-only access — the agent can see order history, account details, and product information — or write access — the agent can place orders, modify subscriptions, and initiate returns. These permission choices are scoped to specific businesses: authorizing your agent to shop at Shopify stores does not automatically authorize it to transact with Stripe or Walmart. Each business relationship requires a separate authorization decision by the customer.

The protocol handles the mechanics of how an agent presents its credentials at a business endpoint, how the business verifies the agent's identity and the customer's authorization scope, and how the handshake is logged for audit purposes. What the protocol does not yet define — and where the draft status matters — is the revocation mechanism (how a customer withdraws agent access), the dispute resolution process (who is liable when an agent misinterprets a permission), and the governance model for who can certify a compliant implementation.

Sierra has framed the announcement as an open standard — available for any business or agent provider to implement without a license fee or a governing body approval. That framing is strategically important: it positions PAP as infrastructure rather than a Sierra product, which makes it easier for competitors, including OpenAI and Anthropic, to implement without appearing to endorse a rival's proprietary system.

The PACT Protocol: The Technical Foundation Underneath PAP

One detail that distinguishes PAP from a pure announcement is the existence of an implementation-ready predecessor. PACT — the Protocol for Agent and Customer Trust — was developed by Decagon and Instinct, two AI companies that are also PAP founding partners, and is available under the Apache 2.0 license. PACT is built on A2A (Google's Agent-to-Agent protocol) and OAuth 2.0, making it compatible with the existing identity infrastructure that both agent providers and businesses already run.

Decagon is bringing PACT to the PAP working group as a concrete technical foundation rather than requiring the working group to design a new protocol from scratch. The relationship between PACT and PAP is roughly analogous to the relationship between a specific authentication mechanism and the broader authorization framework it operates within — PACT provides the specific token format, agent identity credential structure, and A2A communication mechanics, while PAP provides the higher-level trust model and permission schema that businesses implement PACT within.

The Apache 2.0 licensing is strategically significant. It means any business, agent provider, or platform can implement PACT-based interactions without a commercial license, and any modification to the reference implementation can be used in a proprietary product without triggering license fees or source disclosure requirements. This is the licensing model that made OAuth 2.0 ubiquitous: the core spec was open, which removed the commercial incentive for any single vendor to control access to the standard.

The stack from A2A to PAP is entirely open and patent-unencumbered at the current draft stage. That is not a coincidence — it is the architectural choice that makes enterprise and developer adoption plausible at scale, because any proprietary component in the stack creates a veto point that competitors can use to block adoption.

The Commerce Partners and the Signals Their Participation Sends

The founding business partners are the clearest signal of where PAP's initial deployment surface is. Shopify, Stripe, and Walmart are not incidental choices — they are the three organizations that together cover the complete agentic commerce transaction stack.

Shopify is the infrastructure layer for independent commerce: millions of merchants, hundreds of millions of products, the API layer that most agentic commerce experiments have run through first because it already has developer-accessible endpoints. A Shopify implementation of PAP means that any personal agent can browse, compare, and purchase from any Shopify merchant with a single standard interaction model rather than requiring a Shopify-specific integration.

Stripe is the payment layer: the financial rail that processes transactions for hundreds of millions of online buyers and sellers. Payment authorization is the most security-critical step in any agentic commerce interaction — the step where the identity and permission verification requirements are highest. Stripe's participation signals that PAP is being designed to satisfy payment processing security standards, not just consumer convenience requirements.

Walmart is the large-format retail anchor: a business whose agentic commerce surface spans physical stores, online ordering, grocery pickup, and financial services. Walmart's presence demonstrates that PAP is not limited to digital-native commerce — it extends to the highest-volume physical-digital retail context in the country.

The agentic commerce infrastructure signal from DoorDash's text-to-order agent is relevant context here: DoorDash built its agent interaction through a proprietary integration. PAP is the standard that would let a personal agent order DoorDash delivery without requiring a DoorDash-specific integration — the same protocol that routes to Shopify, Stripe, and Walmart would route to DoorDash once it implements PAP.

The partners that are notably absent — Amazon and Apple — are the ones with the most to lose from an open standard. Amazon has a proprietary agent shopping interface in Alexa+ and a vested interest in keeping agent interactions flowing through its own protocol layer. Apple is building its own agent orchestration in iOS 27. Neither company has publicly endorsed PAP, which suggests that the standard will face the same adoption tension that every open standard in a market with dominant platform incumbents faces: the platforms that benefit most from openness adopt early, and the platforms with the most to protect resist.

The OpenAI Expansion and What It Means

The October 9 expansion of the design partner list to 35 organizations, with OpenAI among them, shifts the protocol from a Sierra-Meta initiative to something that looks more like an industry standard. OpenAI's participation is the most significant single addition since the founding announcement: it means that ChatGPT's agentic capabilities — including the persistent Dots agents that run autonomously across connected applications — have a path to implementing the PAP identity layer.

OpenAI's participation also creates a standardization forcing function for competing agent providers. When the provider of the most-used consumer AI agent system joins the design partner group, competing providers face a choice: implement the same standard (which benefits all agents equally) or implement a different standard (which fragments the ecosystem and forces business partners to maintain multiple implementations). The historical pattern from payment protocols, messaging standards, and identity federations suggests that once the largest participant joins, holdouts either join or are isolated from the markets the standard covers.

The enterprise AI trust problem is precisely the issue PAP is designed to address from the business side. Enterprises pulling back from autonomous agent authority because they cannot verify that agents are acting within authorized scope is a governance problem; the inability to verify that a personal agent is acting with real customer consent is a trust mechanics problem. PAP solves the trust mechanics problem for commerce interactions specifically — the category where the stakes of misauthentication are highest, because unauthorized purchases, financial liability, and account takeover risk are all in scope.

Cloudflare's decision model approach to agentic enterprise interactions represents the enterprise-side complement to PAP: Clef defines how businesses make real-time authorization decisions about what agents are permitted to do; PAP defines how agents present their identity and customer authorization claims for Clef to evaluate. The two standards are complementary rather than competing — PAP handles identity and consent at the protocol level, Clef handles policy enforcement at the business logic level.

The Governance Gap and Why It Matters

The most significant weakness in the October 6 announcement is the governance question. An open standard that no one governs is not a standard — it is a proposal. The history of identity and authentication standards is littered with technically sound proposals that fragmented because the governance model could not hold competing interests together. SAML had the OASIS consortium. OAuth 2.0 had the IETF. OpenID Connect had the OpenID Foundation. PAP currently has a working group whose membership and decision processes have not been publicly described.

The governance question matters for three reasons. First, it determines who resolves specification disputes when implementations diverge — which they will, because implementations always diverge. Second, it determines who maintains the security profile of the protocol over time, including revocation mechanisms, audit logging requirements, and liability standards that evolve with the threat landscape. Third, it determines whether businesses can rely on a PAP implementation remaining stable, or whether the specification will be revised in ways that break existing deployments.

The fact that the spec is still in draft and the governance structure is not yet public is not disqualifying — it is an accurate reflection of how standards get built. The risk is not that PAP is unfinished; the risk is that the governance question gets answered in a way that gives any single participant — Sierra, Meta, or a future large adopter — disproportionate control over the specification's evolution. Open standards governed by single companies are controlled standards in practice, regardless of the open-source licensing.

For enterprise buyers and developers evaluating whether to implement PAP now, the governance question is the key due-diligence item. An Apache 2.0 reference implementation plus a stable draft spec is sufficient for early adopter experimentation. Production deployment at enterprise scale needs a governance model that ensures the spec remains stable, secure, and independently maintained.

The Distribution Implications for Enterprise SaaS

For enterprise SaaS vendors, the Personal Agent Protocol has a specific and underappreciated implication: it moves the primary agent integration surface from the vendor's own proprietary API to the vendor's PAP implementation.

In the pre-PAP world, connecting an enterprise AI agent to a SaaS vendor's data requires either the vendor's proprietary API (with its own authentication model, rate limits, and data schema) or a managed integration through a middleware platform like Zapier, Make, or an enterprise iPaaS. Each integration is custom. Scale requires either a large integration portfolio or deep investment in middleware.

In a post-PAP world, a SaaS vendor that implements PAP provides a single integration surface for any personal agent that also implements PAP. An enterprise that has authorized their organization's personal agents to interact with their Jira instance, their Salesforce CRM, their Slack channels, and their Stripe billing portal uses one permission model — the PAP permission schema — rather than four separate API key management schemes and four separate OAuth flows.

The AI agent security gap at 88% of enterprises is largely a gap in exactly this authorization infrastructure. Agents operating in enterprise environments without a verified permission model create attack surface: prompt injection attacks that escalate agent permissions, misauthenticated actions that leave no audit trail, and unauthorized data access that violates compliance requirements. PAP's audit logging and permission scope requirements address the technical layer of this problem — not by preventing attacks, but by ensuring that every agent action is authorized, logged, and attributable to a specific customer consent event.

The competitive dynamic for enterprise SaaS vendors is also notable. A vendor that implements PAP early becomes easier for any personal agent to integrate with, which increases its surface area in the agentic workflow ecosystem. A vendor that delays PAP implementation requires agent providers to build proprietary integrations — a higher-friction option that agents and their users will route around when a PAP-compliant alternative exists.

The Identity Layer Thesis: Where This Goes in 12 Months

The trajectory of the Personal Agent Protocol follows a predictable pattern for infrastructure standards. In the first six months, early adopters build implementations, find edge cases, and report back to the working group. In months six to twelve, the spec stabilizes as the most significant issues get addressed. At the twelve-month mark, either the standard has enough certified implementations to create adoption momentum, or it has fragmented into competing dialects that require reconciliation.

The indicators that suggest PAP succeeds: OpenAI's participation means the most-used consumer agent has a path to implementation; Shopify and Stripe provide the two most critical commerce infrastructure surfaces; PACT gives the working group an Apache 2.0 implementation to standardize against rather than designing from scratch; and the entirely open protocol stack removes the commercial veto risk.

The indicators that suggest PAP struggles: the governance structure has not been defined, the spec is still in draft form, and Amazon and Apple — the two largest agent and commerce platforms — are not participating. An open standard that the two largest potential adopters do not endorse will find its deployment surface limited to the independent commerce ecosystem rather than the full consumer commerce market.

The 12-month question for enterprise architects and SaaS vendors is not whether to implement PAP today — the spec is not stable enough for production use — but whether to architect for PAP readiness. That means two things: ensuring that customer authorization and permission infrastructure is designed to be protocol-agnostic (so PAP or its successor can be wired in without a redesign), and monitoring the working group's governance announcements for the signal that the spec is stabilizing toward production-ready.

Takeaway: The Personal Agent Protocol is the most significant agentic commerce infrastructure announcement of 2026, not because it is finished, but because it is the moment the industry acknowledged that the agent identity problem needs an open standard rather than a collection of proprietary workarounds. The founding partners — Shopify, Stripe, Walmart, and now OpenAI — have enough combined agentic commerce surface to create adoption momentum if the governance question gets resolved correctly. For enterprise SaaS vendors, PAP represents the future integration standard for agent interactions: the earlier the architecture accommodates it, the lower the implementation cost when the spec stabilizes. For enterprise buyers, the implication is simpler: the authorization infrastructure you build for AI agents today should be designed for protocol extensibility, because PAP or its successor will become the default identity layer for agentic commerce within 18 months.