Discovery and session
The personal agent finds the company route and begins a session. PAP is the emerging language for that handshake.
Personal Agent Protocol, PAP and proof before action
Sierra and Meta have announced Personal Agent Protocol as an open standard for how personal AI agents interact with businesses. AffixIO fits around that kind of session by proving whether a specific agent action should be allowed, denied or reviewed before it reaches checkout, support, account changes, MCP tools or OpenAPI routes.
Direct answer: AffixIO does not claim to own PAP or be a Sierra, Meta, Shopify, Stripe or Walmart partner. It provides a proof-before-action layer that can be used around PAP-style personal agent sessions once a business exposes a website, MCP tool, OpenAPI route or company agent.
Agent referenceWhat changed
Sierra described Personal Agent Protocol as starting on a website, letting a personal agent discover what a company offers, then beginning a session on the user's behalf. Public checks can remain guest-level. Account actions can require sign-in or credentials already set up with the personal agent. The customer decides read-only or write access, and the company chooses whether the agent uses the website, APIs such as MCP and OpenAPI, or a company agent.
The personal agent finds the company route and begins a session. PAP is the emerging language for that handshake.
OAuth can describe account access, guest access, read-only access or write access. Access is not the same as approval for every action.
AffixIO can check the exact action, policy, limits, recipient, merchant, expiry and evidence requirements before execution.
Architecture
The cleanest implementation is to call AffixIO between the agent request and the controlled action. That applies whether the route is a website form, an MCP tool, an OpenAPI endpoint, a checkout step, a support workflow or a company-owned agent.
The business makes clear what an agent can do and which interface it should use.
The agent acts as guest or with user-approved account access.
The request has an action, target, account, amount, merchant or tool context.
The policy check returns allow, deny or review with signed decision evidence.
The website, API or company agent executes only if the result allows it.
Support, risk, compliance and future disputes share the same proof record.
Working model
This demo keeps the payment rail, website or MCP server separate. It shows the proof-before-action question a business should ask before letting the agent proceed.
Use cases
Personal agents will not only browse. They will ask to return products, change subscriptions, book services, update details, claim warranties, call paid tools and trigger purchases. Each action needs a business-grade decision, not just a friendly chat transcript.
Before checkout, prove the agent has the right mandate, amount ceiling, merchant scope and expiry.
Before a refund, warranty claim or account change, prove the agent has the right account context and allowed action.
Before tool invocation, prove the agent can see and call that tool for this user and this purpose.
Let agents check availability, status or policy without accidentally granting write authority.
Separate permitted edits from account takeover risk by binding scope, account and intended outcome.
Keep a signed record that answers what was requested, what was checked, and why the system allowed or blocked it.
Clear boundaries
| Layer | Question it answers | AffixIO role |
|---|---|---|
| Personal Agent Protocol | How can a personal agent discover and interact with a business? | Use the session and route context as inputs for decision evidence. |
| OAuth | Has access been authorised for this account or resource? | Check whether the requested action is within policy right now. |
| MCP or OpenAPI | Which tools or endpoints are available? | Gate visibility and invocation before the tool or endpoint runs. |
| Payment rail | Can money move through the processor or wallet? | Prove the action, authority and transaction intent before payment execution. |
FAQ
No. This page references public reporting and explains where AffixIO can fit technically. It does not claim a partnership with Sierra, Meta, Shopify, Stripe, Walmart or any other named organisation.
No. Sierra stated that it plans to publish a v0.1 specification later in October 2026. AffixIO should track the spec when it appears and adapt implementation language accordingly.
No. OAuth can authorise access. AffixIO checks the proposed action under that access and produces evidence for allow, deny or review.
Payments were described as a future extension in the announcement. AffixIO can already model payment intent proof, spend limits and agentic payment checks around existing rails, but payment processors still authorise payment.
Yes, a browser can be the interface or controlled runtime for a personal agent workflow. A normal anonymous tab is not trusted by itself. Protected keys and policy checks should remain on a trusted backend or controlled runtime.
Start by listing actions, classifying them as public, read-only, write, payment or review, then call AffixIO before any write, paid or sensitive action executes.
Read next
Sources
Sierra announced Personal Agent Protocol on 6 October 2026 and described it as an open standard being developed by Meta and Sierra with named industry partners. TNW separately reported the OAuth basis, website, API and company-agent routes, the pending v0.1 specification and payments as a future extension.
PACT consent context
PACT can identify the personal agent and carry user-granted scopes. AffixIO can check the exact action and return yes, no or review evidence before the brand lets it run.