Personal agents need a two-sided delegation receipt

On 13 October 2026, BBVA announced participation in the Personal Agent Protocol initiative alongside a group of 35 design partners. The announcement describes agents acting with user consent while businesses retain control over access to their services. Those are two different permissions, and treating them as one is where an integration can go wrong.

Personal agents need a two-sided delegation receipt. My proposal is a record of what the user authorised and what the counterparty accepted, tied to one identifiable agent and operation. User intent starts the request. It cannot, by itself, settle the business's permitted scope, confirmation rules or route for resolving a disputed action.

Poppy separates intent from accepted access

BBVA's announcement describes user permissions and company limits as parts of the proposed interaction model. Its participation is evidence of design involvement, not proof that a production banking flow is available.

The Personal Agent Protocol path to 1.0 is equally useful for what it leaves unresolved. The specification is a draft, revisions may break compatibility, and payments remain an open topic. A partner list should therefore not be used as a shortcut to assuming interoperable payment execution.

For an engineering team, the practical question is narrower than whether agents will change banking. When an agent reaches a business service, which requested powers does that service recognise, and what evidence will exist if the action is challenged later?

A two-sided delegation receipt binds the operation

I would make the receipt answer seven questions. Who is the principal? Which agent is acting? What scope did the user grant? What scope did the counterparty accept? When is the permission valid and how is it revoked? Which actions require confirmation? Where does a disputed or incomplete action go next?

Those are proposed application fields, not a claim that the Poppy draft already defines this exact object. The value is in comparing the two grants before action and preserving the decision afterwards.

A user might authorise an agent to find a better account. The business might permit product discovery and an eligibility check while requiring a separate confirmation for an application. Collapsing that into “the agent has permission” loses the only part that tells the implementation when to stop.

The receipt also needs a stable operation identity. Otherwise a retry can be mistaken for new consent, or a revised request can accidentally inherit the old scope. Attach the relevant version of the request and the counterparty's response rather than relying on the agent's latest conversation summary.

This is my proposed control flow. An implementation must still establish secure identity, authorisation and storage; drawing a receipt does not provide those properties.

Separate discovery from application authority

Imagine a personal assistant comparing account products for a customer. I would split discovery, retrieval of customer-specific information and submission of an application into separate permitted operations. A successful discovery request should not silently create authority for the next two steps.

Before retrieving private information, the assistant should know whose authority it is presenting and which business endpoint accepted that authority. Before submission, it should check whether the terms or requested action changed and whether an explicit customer confirmation is required.

This is a hypothetical design review, not a bank deployment I tested. Its useful output is a concrete set of refusal cases. An expired permission should stop the next protected action. A narrower business acceptance should constrain the request. A changed product choice should not reuse an unrelated confirmation.

I would also test revocation while a workflow is waiting. A permission checked at the beginning of a long session should not automatically remain valid for a later consequential action. The exact timing and revocation guarantees need to come from the service contract, not from the model's confidence.

Governance needs an observable decision trail

On 15 October, the Financial Stability Board published 12 sound practices for AI adoption. They address governance and risk management across the AI lifecycle. They do not certify this proposed receipt or resolve the allocation of liability for an individual transaction.

My engineering inference is that governance becomes easier to examine when a consequential operation carries its actual decision trail. “The customer wanted it” and “the model selected it” are explanations of intent and behaviour. Neither identifies the business permission that made the action acceptable.

Keep that trail useful without turning it into an indiscriminate copy of private conversations. Store the fields needed to establish scope, version, confirmation and outcome, under the relevant retention and access policies. More captured text does not automatically produce clearer accountability.

The dispute route also deserves an owner before launch. If the remote service accepted a request but the result is unclear, the agent should be able to preserve an unknown outcome and escalate with the operation identity. It should not keep acting until the uncertainty becomes somebody else's problem.

Where the receipt earns its cost

A simple public-information lookup may not need this full treatment. The cost becomes justified when an agent crosses an organisation boundary, uses private data or can create a consequential commitment. Apply controls according to that action, not according to whether the interface happens to look conversational.

The unresolved work is substantial: interoperable identity, scope interpretation, revocation, confirmation and disputed outcomes all require implementation evidence. I have not verified cross-bank interoperability, live payment support or liability outcomes. The receipt is a practical review proposal, not tested banking infrastructure or legal advice.

What's in it for you

• Compare the user's grant with the business's accepted scope before execution.
• Keep operation identity, confirmation and unresolved outcome available for recovery.

An agent should act on the intersection of two permissions, with evidence of how that intersection was accepted.