A proposed technical specification for AI agents that read data and take authorized actions inside third-party personal accounts. Relate MCP, A2A, AP2 and Personal Agent Protocol to secure website execution.
Turn user intent into
a verifiable account action.
MCP connects agents to tools, A2A coordinates agents, and AP2 authorizes payment transactions. Sierra and Meta’s Personal Agent Protocol proposes a shared connection model for personal agents and businesses. Account execution also needs authentication, session continuity, action controls and result verification. Sophtron proposes a common execution profile for that workflow.
Authored by Sophtron · October 10, 2026 · Request for comments
This is a proposed execution profile for discussion, not a ratified industry standard or a claim of adoption by MCP, A2A, AP2 or PAP. Requirements describe the draft design; the JSON examples are not the current Sophtron API contract.
A consented agentic action API lets software retrieve data or perform a defined operation in a user’s account under explicit, scoped and revocable permission.
The proposed Agentic Web Execution Protocol describes the contract between an agent and an execution gateway: identify the account, check permission, establish a session, obtain any required approval, execute the task and return evidence of the result. It applies to personal banking, utilities, insurance, healthcare, retail and subscription accounts.
Account consent grants a bounded set of permissions. Authentication establishes the user’s identity at the destination. Action approval authorizes a specific commitment. These are separate checks. A connected account is not blanket permission to purchase, pay or change its settings.
Roles: the account holder grants permission; the agent proposes work; the gateway enforces policy and coordinates execution; a secure user interface collects authentication or approval; the destination website remains the source of account state.
MUST, MUST NOT and SHOULD below describe requirements of this proposed profile. Transport bindings, operation catalogs and interoperable approval-proof formats remain open design work.
Published specifications and emerging proposals address different responsibilities. Map each to its role in authenticated account execution.
| Protocol / specification | Scope and status | How to apply it here |
|---|---|---|
| Model Context Protocol (MCP) | Tool integration; its HTTP authorization specification governs access to protected MCP servers. | Expose account operations as tools. Authenticate the client and enforce each operation’s permissions at the gateway. |
| Agent2Agent (A2A) | Communication and task coordination between agents, including requests for additional input. | Delegate work to an execution agent. Carry task status and references while preserving the originating user’s authority. |
| Agent Payments Protocol (AP2) | Checkout and payment mandates that bind authorization to commerce transactions. | Use AP2 where participants support it. Its transaction-bound approval and receipt concepts inform this draft’s action controls. |
| Personal Agent Protocol (PAP) Sierra + Meta · announced | A proposed connection model between personal agents and participating businesses. | Discover supported routes and permissions; maintain context across website, API and company-agent interactions. |
| Sophtron execution profile Proposed draft 0.1 | Account-scoped requests, session interruption, action approval, result evidence and uncertain-outcome recovery. | Apply a consistent execution contract behind an API or MCP tool, including websites without a suitable consumer-account API. |
Announced October 6, 2026, Personal Agent Protocol is being developed by Sierra and Meta with partners including Instinct, Shopify, Stripe and Walmart. Sierra describes OAuth-based sessions, user-selected read/write access and continuity across a business’s website, APIs and company agent. The announcement schedules v0.1 for later in October. Read Sierra’s announcement.
Discover available capabilities before execution. Preserve user, account and task bindings across approved channel changes, with credentials isolated from the model. Treat an unavailable operation as a capability gap; switching routes must never expand the grant or bypass an action-approval requirement.
Where a business exposes a suitable interface, an execution gateway can use it. Across accounts without one, Sophtron’s authenticated browser infrastructure supplies an additional execution path under the same consent and action-approval controls. A shared protocol and account-access infrastructure can work together.
AP2 addresses payments; A2A addresses agent coordination; PAP addresses agent-to-business interaction. The proposed mapping does not claim Sophtron partnership, certification or implemented PAP interoperability.
“MCP auth layers” is descriptive terminology here—not the name of a separate MCP standard.
For protected HTTP MCP, follow its authorization specification: discover authorization metadata, use the required OAuth flow and PKCE, and validate tokens for the intended resource. The gateway separately checks the caller, tenant, linked account and operation.
Use the destination’s own authorization mechanism: an appropriate API token where available, or a user-authenticated website session. Keep upstream tokens, passwords and session cookies in the secure execution environment, outside model prompts and tool results.
Collect approval in a trusted interface for critical or irreversible operations. Bind it to the account, operation, exact parameters, limits and expiration. A model-generated “approved” value cannot replace this record.
MCP prohibits token passthrough. A token issued for the MCP server must not become the credential sent to a retailer, bank or utility. See MCP security guidance.
MFA pass-through means a secure user handoff: the person completes the destination’s verification while the agent receives only task status and an opaque continuation reference.
The gateway MUST bind an authentication continuation to the same user, tenant, account and task, with a short expiry and single-use completion. Resume only after verifying the destination session and rechecking consent. Session recovery cannot revive an expired or revoked grant.
Keep connection state separate from task state: a session can require reauthentication while the task waits. Automatic CAPTCHA handling belongs to access infrastructure; it is not a substitute for account-holder authentication or action approval.
For purchases, payments and consequential account changes, show verified terms in a trusted interface before the final commitment.
Approval MUST bind to an immutable action record: destination account, operation, item or payee, quantity, full cost, currency, fulfillment or target setting, and expiry as applicable. Store the user’s decision through an authenticated channel the agent cannot impersonate. Changed material terms require a new decision.
The executor MUST recheck authority and the bound terms immediately before commitment. If a website cannot atomically enforce them, the adapter must verify them at its final submission boundary and fail closed when it cannot establish a match.
AP2’s Agent Authorization Framework provides a useful model for proving permission to a verifier. This draft adapts the principle to account actions. A local approval record does not become an AP2 mandate merely because it uses similar fields.
An example purchase request shows the proposed shape. Read operations use their own parameter schema and need only the corresponding read grant.
{
"profile": "sophtron.agentic-web-execution/0.1",
"request_id": "req_demo_001",
"idempotency_key": "checkout_demo_001",
"account_ref": "acct_retail_demo",
"consent_ref": "consent_demo",
"operation": "retail.order.submit",
"parameters": {
"item_ref": "item_demo",
"quantity": 1,
"max_total_minor": 7500,
"currency": "USD",
"fulfillment_ref": "delivery_demo"
},
"expires_at": "2026-10-10T19:00:00Z"
}account_ref + consent_refOpaque references resolved against authenticated identity. Possessing the strings alone grants no authority.
operation + parametersA typed operation, its target and limits. 7500 USD minor units means a $75 maximum including required charges.
idempotency_keyBind to the caller, account and immutable request. Reuse returns the existing task; changed input produces a conflict.
expires_atThe latest permitted commitment time. The gateway enforces the earlier of request expiry, consent expiry and approval expiry.
The example timestamp is fixed sample data, not a current authorization. The schema validates this checkout example’s shape only. Consent, account binding, currency validity, expiry, approval and website behavior require runtime checks. For live endpoints, use Sophtron’s Action API documentation.
An execution gateway needs to distinguish “not performed” from “may have happened.” This matters whenever repeating an action could create a duplicate commitment.
| Draft task state | Meaning | Required next step |
|---|---|---|
| received / validating | Request accepted for policy checks; no commitment. | Validate ownership, grant, operation, limits and expiry. |
| authentication_required | Destination sign-in or MFA is needed. | Pause for secure user completion; then revalidate the task. |
| approval_required | A material action is ready for the user’s decision. | Obtain bound approval. Denied or expired tasks cannot commit. |
| executing | The adapter is performing the approved task. | Use a durable per-action lock and record submission state. |
| succeeded | The destination confirms the requested result. | Return a receipt with the observed result and evidence reference. |
| outcome_unknown | The action may have committed, but confirmation is missing. | Read back destination state. Do not resubmit until reconciled. |
| denied / expired / failed / cancelled | Work stopped before commitment, or the destination confirms rejection. | Report the reason. Cancellation is not a promise to undo a completed action. |
The gateway MUST return the task ID, operation, account reference, approval reference when applicable, timestamps, outcome and destination confirmation or evidence reference. Keep secrets and unnecessary personal data out of receipts. Distinguish a gateway-generated record from a merchant-signed receipt; they have different evidentiary value.
Idempotency keys protect the gateway from duplicate requests; they cannot guarantee exactly-once effects at a website. Use durable submission records and destination reconciliation. If an outcome cannot be established, retain outcome_unknown and escalate for review. Revocation blocks future work; it cannot retroactively reverse a submitted order or payment.
Reject a cross-tenant account reference; stop a revoked grant; reject an agent-forged approval; pause when approved terms change; reject mismatched retries; reconcile a lost checkout response without submitting twice. Draft 0.1 publishes these expected behaviors, not a certification program.
A protocol describes the contract. Completing work inside personal accounts requires browser, authentication, challenge-handling and session infrastructure.
Sophtron combines its own browser and automation framework, automatic unblocking, in-house CAPTCHA models and a decade of account-connectivity engineering. Its Access & Action API gives agents access to personal-account data and user-authorized tasks.
Use the API for execution workflows and the published Sophtron MCP integration for the tools it exposes. The proposed profile documents how a consistent permission and execution contract can sit around those capabilities.
Read purchases and wishlist details, monitor selected deals, then prepare an order for user-approved checkout.
Retrieve usage and bills, review recurring charges and carry out approved account changes.
Retrieve balances, rewards, coverage or claims; keep sensitive changes behind an explicit user decision.
The draft’s state names, envelopes and conformance requirements are proposed design. They do not assert that every field is implemented in today’s API. AP2, A2A and PAP are architectural references, not announced Sophtron partnerships.
Primary references reviewed October 10, 2026. Protocol-specific claims follow the linked sources; the execution requirements on this page are Sophtron’s proposal.
Initial proposal: trust boundaries, session continuation, exact-action approval, example request shape and uncertain-outcome handling. Reference update: added Sierra and Meta’s Personal Agent Protocol announcement and its proposed relationship to account execution. Feedback sought on transport bindings, operation schemas and portable approval evidence.
Send specification feedback →It is Sophtron’s draft proposal for discussion. It has not been ratified by a standards body and does not claim adoption by MCP, A2A, AP2 or PAP. The page separates those projects’ published specifications from its proposed execution requirements.
Separate client authorization, destination authentication and action approval. Enforce account-level permissions at the gateway, keep credentials in a secure connection path, pause for required MFA, check approval before consequential actions, and return evidence of the outcome.
No. MCP authorization governs access to the MCP server. The server still needs an appropriate authentication and execution mechanism for the destination account, along with the user’s permission for the requested operation.
A2A coordinates work between agents. AP2 provides authorization mechanisms for payment transactions. This draft describes execution within authenticated personal accounts, including session handling, user decisions and recovery. It draws on those protocols without replacing them.
PAP informs the proposed protocol mapping. Sophtron supplies account-access infrastructure; this page does not announce PAP implementation or a Sierra/Meta partnership. See the Personal Agent Protocol discussion for the architectural relationship.
Yes. The proposed gateway contract can sit over an API adapter or an authenticated website adapter. Sophtron provides browser and account-access infrastructure for the latter. User authorization does not itself create platform permission or an exemption from the destination’s access requirements.
No. In this proposal, the user completes verification through the secure connection interface. The agent sees that authentication is required or completed, plus an opaque continuation reference. It does not receive passwords, codes or session cookies.
No. The gateway must obtain and verify a user approval record for critical or irreversible commitments. An agent-generated flag, prompt or tool response cannot satisfy that requirement.
The gateway reports outcome_unknown until it can determine the destination’s state. It checks for an order or confirmation before any further submission. A timeout alone is not evidence that the order failed.
The published API and MCP documentation define today’s interfaces. The envelope, state names and conformance cases on this page are proposed design, with downloadable illustrative JSON and a shape-validation schema for technical review.
Connect your product to personal accounts with Sophtron’s access infrastructure and user-controlled actions.