Consent, Authority and Scopes Standard
Version: 0.1 (Draft for Comment)
Status: Working Draft. The keystone meta-standard.
Steward: Marrow (trymalcolm.com), on behalf of the Agent-to-Agent (A2A) working group
Scope: What an AI agent is authorised to do on a user's behalf when buying or servicing regulated insurance, how that authority is proven, scoped, exercised, and revoked
This is the meta-standard that makes agent-mediated insurance transactable. The A2A Core Patterns Standard says how an agent must behave; this standard says what it is permitted to do, and on whose authority. It is deliberately built on top of the agentic-commerce rails the platforms have already shipped, and defines only the regulated, insurance-specific authority semantics that those rails do not cover. Comments to standards@trymalcolm.com.
1. Why this standard exists, and where it sits
An agent can be perfectly well-behaved and still must not bind a policy or move money unless it holds proven, scoped authority to do so. That authority question is the actual unlock for agent-mediated insurance, and it is the first thing an agent platform and a regulator will each examine. Generic agentic-commerce standards now answer most of the plumbing for retail purchases. They do not answer the parts that make insurance regulated: lawful processing of sensitive personal data, mandatory disclosure before sale, suitability and Consumer Duty, and an ongoing policy relationship rather than a one-shot checkout. This standard defines those, expressed so they ride on the existing rails rather than duplicating them.
It depends on the Core Patterns Standard (for behaviour) and is depended on by every interaction standard (New Business, MTA, Renewal, Claims) and every LoB standard (which reference it for authentication and transaction authority).
2. Relationship to the agentic-commerce standards (interoperate, don’t reinvent)
By mid-2026 the payment, agent-identity, and consent plumbing for agent commerce exists and is converging. This standard interoperates with it and layers the insurance-specific semantics on top.
- Agentic Commerce Protocol (ACP), maintained by OpenAI and Stripe (with Meta), live in ChatGPT since late 2025. Provides agentic checkout, delegate authentication (OAuth 2.0, agent acts on the buyer's behalf with a business), and delegate payment (payment tokens passed between buyer, agent, and business via payment handlers). Marrow consumes ACP delegate-authentication for the buyer-to-business authorisation and ACP delegate-payment so the rail never touches a raw card.
- Agent Payments Protocol (AP2), originated by Google and donated to the FIDO Alliance for open governance in May 2026. Defines three signed Mandates (Intent, Cart, Payment) carried as W3C Verifiable Credentials. Marrow expresses authority against these mandates: an Intent mandate is the pre-authorised, capped grant; a Cart mandate is the specific quote being bound; a Payment mandate is the payment authorisation.
- Visa Trusted Agent Protocol (Verified Agent ID, plus an issuer-signed consumer consent record) and Mastercard Agent Pay (Agentic Tokens binding a tokenised card to a specific agent, merchant scope, and consent policy). These are network implementations converging on AP2 compatibility. Marrow consumes their agent-identity and agent-merchant-scope primitives as proof of who the agent is.
The division of labour is the positioning: those standards prove the buyer authorised a payment to a business and that the agent is who it claims to be. This standard adds what a regulated insurance bind additionally requires, and is the layer that makes an AP2 or ACP mandate valid for insurance rather than just for retail. Marrow is the regulated authority layer the commerce rails plug into.
3. Design stance
Three decisions fix the shape of this standard.
Identity is method-agnostic; Marrow defines the semantics, not the login. The rail consumes identity from whatever proves it: the surface's verified user token, ACP delegate-authentication, carrier OAuth (MyAviva-style) for policy-specific actions, and agent identity from Visa Verified Agent ID or Mastercard Agentic Tokens. Marrow does not own authentication; it defines the authority and scope semantics that sit on top of whatever identity is presented.
Step-up confirmation is the default; autonomy is a separate, higher tier. Per-transaction human confirmation is required for contract-changing and payment actions by default (Tier A). A pre-authorised, capped, autonomous mode (Tier B) is available as a distinct, higher-scrutiny conformance tier that a user and carrier opt into. Both are defined in Section 6.
Interoperate and layer on top. Authority is expressed against ACP and AP2 primitives wherever they exist, and this standard defines only the insurance-specific semantics above them (Section 5).
4. The authority model
4.1 Action risk classes
Authority attaches to the risk class of the action, not the product line (defined in the A2A Protocol Meta-Standards Framework):
| Class | Action | Authority required |
|---|---|---|
| 0 Read | Read public product information | None |
| 1 Quote | Process personal data to produce a quote, no commitment | Data-processing and per-source enrichment consent |
| 2 Transact | Create or change a contract and move money | Authenticated identity, explicit scoped authority, confirmation per tier |
| 3 Claim | Act on a loss event | Authenticated identity, explicit scoped authority, heightened care |
4.2 The scope ladder
Authority is granted as granular, time-boxed, revocable scopes. Each is granted explicitly, recorded, and independently revocable. Sensitive and special-category scopes are never bundled into a general grant.
| Scope | Class | Notes |
|---|---|---|
read:product | 0 | Public product and market data. No grant needed. |
process:personal-data | 1 | Lawful basis to process the customer's personal data for a quote, under UK GDPR. |
enrich:<source> | 1 | Per authoritative source. Low-sensitivity sources (for example enrich:companies-house) may be implied by process:personal-data; sensitive sources (enrich:dvla, enrich:cue, enrich:vet-records) require their own explicit grant. |
screen:medical | 1 | Special-category data (travel, pet vet records). Separate explicit consent; heightened protection. |
quote | 1 | Obtain and compare quotes. |
acknowledge:disclosures | gate | Not a grant but a required precondition state: the customer has acknowledged the IPID, key exclusions, warranties, price and credit terms, and any signpost. A bind is invalid without it. |
bind:limit<=£X | 2 | Authority to bind, capped. |
pay:limit<=£X | 2 | Authority to pay, capped; executed via a delegated payment token, never a raw card. |
amend | 2 | Mid-term adjustments to a held policy. |
cancel | 2 | Cancellation, including within cooling-off. |
renew:auto | 2 | Authority to renew without re-confirmation, capped and time-boxed; interacts with the renewal fair-value duty. |
claim:fnol | 3 | Notify a loss. |
advise | cross | Enables advised-sales mode with a recorded demands-and-needs assessment; otherwise information-only applies. |
4.3 Mapping scopes onto external mandates
Where the surface supports them, scope grants are expressed as or bound to commerce mandates rather than a Marrow-proprietary token:
- A capped, time-boxed pre-authorisation (Tier B) is an AP2 Intent mandate (a signed W3C Verifiable Credential) carrying the bind and pay caps and an expiry.
- The specific quote being transacted is an AP2 Cart mandate; the payment authorisation is an AP2 Payment mandate, executed through ACP delegate-payment or a network Agentic Token so the rail never holds card data.
- The agent's identity is the Visa Verified Agent ID or Mastercard Agentic Token; buyer-to-business authorisation is ACP delegate-authentication over OAuth 2.0.
4.4 What insurance adds on top
These are the semantics generic commerce mandates do not carry, and the reason a regulated authority layer is needed:
- Data-processing and special-category consent. A retail mandate authorises a payment; it does not establish a lawful basis to pull a DVLA or CUE record or to process medical screening data. The
process:personal-data,enrich:<source>, andscreen:medicalscopes do, per source, under UK GDPR. - Disclosure-acknowledgement as a bind precondition. A Cart or Payment mandate for insurance is valid only if
acknowledge:disclosuresis satisfied: the customer has been shown and has acknowledged the IPID, exclusions, warranties, price and credit terms, and any mandatory signpost. The rail must refuse to exercisebindwithout it. - Suitability and Consumer Duty conditions. Authority carries conditions absent from retail commerce: adequacy checks (for example the home rebuild-cost and travel cover-limit rules), fair value, and vulnerability handling. A grant does not override these.
- Lifecycle authority. Insurance is an ongoing relationship, not a one-shot checkout. Scopes such as
amend,renew:auto, andclaim:fnolextend authority across the policy life, each capped and independently revocable, which retail mandate flows do not contemplate. - Regulated revocation and cooling-off. The customer's statutory cancellation rights (including the 14-day cooling-off period) interact with and survive any granted authority.
5. Agent identity and attestation
For any Class 2 or 3 action the agent must present a verifiable identity: a registered agent operating under known terms, evidenced by a Visa Verified Agent ID, a Mastercard Agentic Token, or an equivalent attestation the rail trusts. The rail records which agent exercised which authority. A registered agent is one that has attested to operating in conformance with the A2A standards; the governance of that registry is an open question (Section 9).
6. Authentication, confirmation, and the two conformance tiers
6.1 Authentication
Class 0 needs none. Class 1 needs the customer's consent to process their data, not necessarily proof of identity. Classes 2 and 3 require authenticated proof that the user is entitled to act on the policy or to bind: the surface's verified user token for the person, and carrier OAuth for access to an existing policy. The rail consumes these; it does not define the login.
6.2 Tier A: Assisted authority (default)
Every Class 2 and 3 action requires a fresh, human-present confirmation at the point of action. In mandate terms, the human-present Cart and Payment mandates are signed at the moment of the bind. The agent prepares everything; the human confirms each bind, payment, amendment, or claim. This is the default and the regulator-friendly baseline.
Step-up on surfaces the rail does not own. The rail does not need to own the confirmation UI. It specifies the required content of the confirmation (the premium, the key exclusions, the data and enrichment consents being exercised, and the cap) and consumes the surface's human-present signed mandate as evidence that the confirmation occurred. This is how step-up renders inside ChatGPT or Claude without Marrow owning the surface: the platform provides the human-present signing, the standard specifies what must be in it.
6.3 Tier B: Delegated authority (opt-in, higher scrutiny)
The user pre-signs a capped, time-boxed authorisation (an AP2 Intent mandate) granting autonomy within limits, for example "renew my motor policy up to £900 without asking" or "bind home cover up to a set premium". The agent may then act with an agent-present Cart mandate inside those caps without a per-transaction human step. Tier B requires stronger agent identity, explicit and tightly bounded caps, full audit of every exercise against the pre-authorisation, and one-tap revocation. It is where genuinely autonomous insurance buying lives, and it carries the heaviest conformance and disclosure requirements.
A conformant agent declares the tier it operates at. A carrier or user may restrict a product or relationship to Tier A.
7. Consent: granularity, sensitivity, and revocation
Consent is granular (per scope and, for enrichment, per source), purpose-bound (to the transaction at hand), and revocable at any time. Special-category data (medical screening, vet records) always requires its own explicit consent and is never implied by a general grant. Every grant carries an expiry. Revoking a scope takes effect immediately for future actions and is recorded; it does not unwind a completed regulated transaction, but it stops any further exercise (for example cancelling renew:auto before the next renewal). The customer can see the scopes they have granted and revoke any of them.
8. Audit
Every grant, every exercise of a scope, every step-up confirmation or pre-authorisation, and every revocation is recorded in the tamper-evident audit ledger defined in Core Patterns Section 2.10, including the mandate references (Intent, Cart, Payment) and the agent identity that acted. The authority record is the evidence base for demonstrating, to a carrier's compliance function and to the FCA, that every regulated action was properly authorised, that disclosures preceded the bind, and that special-category data was processed only with explicit consent.
9. Conformance, versioning, and open questions
An agent conforms by implementing the scope model (Section 4), the authentication and tier requirements (Section 6), and the consent and audit requirements (Sections 7 and 8), at a declared version and a declared autonomy tier. Conformance composes with Core Patterns: an agent declares Core Patterns vN and Consent, Authority and Scopes vN.
Open questions:
- The registered-agent registry: who operates it, what attestation is required, and how it relates to Visa Verified Agent ID and the FIDO-governed AP2.
- Cap semantics for Tier B: how caps are expressed for products where the premium is not known until quote (most of insurance), for example caps as a ceiling with a re-confirmation trigger above it.
- Renewal autonomy versus fair value: how
renew:autois reconciled with the Consumer Duty fair-value duty so autonomy does not entrench a poor-value renewal. - Cross-surface revocation: how a revocation made in one surface propagates to authority exercised through another.
- Claims authority depth: how far
claim:fnolextends before mandatory handover, given fraud and liability sensitivity.
Published as an open standard. Marrow stewards the drafting but does not assert proprietary control over the interface; it interoperates with the agentic-commerce standards named above and defines the regulated authority semantics on top. Carriers, agent platforms, payment networks, and regulators are invited to shape it.