Consent, Authority and Scopes Standard
Version: 0.2 (Draft for comment)
This version: 2026-09-01
Status: Working draft. The keystone meta-standard.
Licence: CC BY 4.0 (text). Schemas, when published, under Apache 2.0.
Conventions: RFC 2119 keywords and addressed roles
Steward: Marrow (onmarrow.com), on behalf of the Agent Mediated Insurance (AMI) 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 AMI 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@onmarrow.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 September 2026 the payment, agent-identity and consent plumbing for agent commerce exists and is converging, and it has already changed shape twice since this standard's first draft. This standard interoperates with that plumbing and layers the insurance-specific semantics on top. It does not assume any single protocol wins, and it records the state of each at the date of this version so that implementers can see what is live, what is specified, and what is still intent.
- Agentic Commerce Protocol (ACP), published by OpenAI and Stripe as founding maintainers with a stated intent toward neutral stewardship. The specification (latest release 2026-04-17) defines checkout sessions, carts scoped to a single seller, product feeds, orders, delegate authentication (OAuth 2.0 plus 3DS2, the agent acting for the buyer with a business) and delegate payment (payment tokens passed between buyer, agent and business through payment handlers so no party other than the handler holds card data). It also defines an MCP transport binding for the checkout operations and a seller-side discovery document at
/.well-known/acp.json. In practice ChatGPT withdrew its native Instant Checkout in March 2026 and now uses ACP for discovery, with the purchase completed on the seller's own surface; ChatGPT plugins may transact only physical goods and must use external checkout. This standard uses ACP's delegate-authentication and delegate-payment definitions where a surface supports them, and its discovery-document pattern as the model for the AMI well-known document. - Agent Payments Protocol (AP2), originated by Google and contributed to the FIDO Alliance on 28 April 2026 (v0.2), with Mastercard's Verifiable Intent contributed alongside it. It defines three signed Mandates (Intent, Cart, Payment) carried as verifiable credentials, and v0.2 adds human-not-present flows. This standard expresses authority against those 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. At the date of this version no consumer surface has shipped AP2 payments and Visa is not a participant, so the mapping in section 4.3 is a binding for when the surface supports it, not a dependency.
- Universal Commerce Protocol (UCP), published by Google with a group of retailers, platforms and payment providers from January 2026 and released in dated versions. It defines a business discovery profile at
/.well-known/ucp, capability negotiation, and transports over REST, MCP and A2A, with AP2 mandates as an extension. Its shopping surfaces are fed from Google Merchant Center, whose content policy currently excludes insurance and services, so UCP is not a route to market for insurance today. This standard aligns its discovery document and transport bindings with UCP's so that the same endpoint can be described to any of the three ecosystems. - Visa Trusted Agent Protocol (agent identity through HTTP Message Signatures, built with Cloudflare and Akamai on Web Bot Auth, with a Visa-operated agent registry and 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). Both networks completed their first live European transactions in mid-2026 with UK issuers participating. This standard consumes their agent-identity and agent-merchant-scope primitives as evidence of who the agent is.
- Model Context Protocol (MCP) and the A2A (Agent2Agent) protocol, both governed within the Linux Foundation's Agentic AI Foundation. MCP is the protocol behind ChatGPT plugins, Claude connectors and Gemini's custom apps, and the transport this standard's New Business interaction binds to. A2A defines agent-to-agent messaging and discovery through Agent Cards; no consumer assistant consumes A2A agents at the date of this version, so the A2A binding is provided for interoperability rather than relied upon.
The division of labour is the positioning: those standards prove that 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 sale additionally requires, and is the layer that makes an ACP or AP2 mandate valid for insurance rather than only for retail. Marrow is the authority layer for regulated insurance that the commerce rails plug into.
One consequence of the current platform rules matters for every implementer. Because the consumer surfaces do not permit an insurance bind or a premium payment inside the conversation, the human-present confirmation this standard requires (section 6.2) takes place on a hosted confirmation surface provided by the intermediation layer or the carrier, reached from the conversation. This standard specifies the content of that confirmation; it does not require any particular surface to render it.
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 a Visa Trusted Agent signature or a Mastercard Agentic Token. 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 AMI Meta-Standards Framework):
| Class | Action | Authority required |
|---|---|---|
| 0 Read public data | Read public, non-personal product and market information only | 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 |
Relay-graded authority
The relay over which an action runs (Core Patterns 3.11, Communication pathway and delivery fidelity) is part of its authority condition. Read (public) and quote MAY run over any relay. Transact and claim require a relay whose delivery is provable, a direct or structured relay, and MUST NOT complete over a narrated relay, because the customer's sight of the required content cannot be proven there. A weak model MAY relay the conversation; it MUST NOT bind.
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 only. No grant needed. Does not cover personal data or policy data. |
read:policy | 1 | Read a customer's own policy and policy documents. Requires authenticated identity. Used by servicing, MTA, renewal and claims. |
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. Where an amendment would increase the premium beyond the pre-authorised cap, step-up confirmation is required rather than proceeding autonomously. |
cancel | 2 | Cancellation, including within the cooling-off period that applies to the product (14 days for general insurance, 30 days for life and protection contracts). |
renew:auto | 2 | Authority to renew without re-confirmation, capped and time-boxed; interacts with the renewal fair-value duty. A renewal that would exceed the pre-authorised cap triggers step-up confirmation rather than proceeding autonomously. |
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 to a proprietary token. Where the surface does not yet support them, the intermediation layer records an equivalent grant with the same fields and the same audit treatment, so that a journey completed today can be re-expressed against the mandates when they arrive.
- A capped, time-boxed pre-authorisation (Tier B) is an AP2 Intent mandate 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, a network Agentic Token, or the carrier's own payment page reached from the hosted confirmation surface, so that the intermediation layer never holds card data in any of the three cases.
- The agent's identity is a Visa Trusted Agent signature, a Mastercard Agentic Token, or the surface's own verified agent identity; buyer-to-business authorisation is ACP delegate authentication over OAuth 2.0 where the surface offers it, and otherwise the surface's verified user token.
4.4 What insurance adds on top
These are the semantics generic commerce mandates do not carry, and the reason an authority layer for regulated insurance 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 intermediation layer 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 cancellation rights. The customer's statutory cancellation rights, including the cooling-off period that applies to the product (14 days for general insurance, 30 days for life and protection contracts), 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 Trusted Agent signature, a Mastercard Agentic Token, a platform-issued agent identity, or an equivalent attestation the intermediation layer trusts. The layer records which agent exercised which authority. A registered agent is one that has attested to operating in conformance with a declared version of the AMI standards and is listed on the implementers register (see the Oversight and Assurance standard). At the date of this version the United Kingdom has no statutory definition of agent identity and no registry of agent operators; the AMI implementers register is offered as an interim answer and is designed to defer to a national or network registry when one exists. The governance of that register 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 most conservative 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.
Cap semantics across scopes. amend and renew:auto carry the same cap semantics as bind:limit and pay:limit: an action whose premium falls within the granted cap proceeds autonomously, and a change that would take the premium beyond the granted cap triggers step-up confirmation rather than proceeding.
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 immutable audit ledger defined in Core Patterns Section 3.10, including the mandate references (Intent, Cart, Payment) and the agent identity that acted.
Every refused Class 2 or Class 3 action MUST also be recorded, with the reason for the refusal: for example acknowledge:disclosures not satisfied, a cap exceeded, no verifiable agent identity presented, identity not authenticated for the policy, or a relay whose delivery is not provable. The refusal record carries the same fields as an exercise, so that the action that did not happen is as traceable as the action that did. Without it, an implementation whose controls fired and an implementation whose controls were never reached look identical in the ledger, and the enforcement this standard depends on cannot be evidenced.
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 the Visa-operated agent registry and to AP2 under FIDO Alliance stewardship.
- 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. Cap semantics for
amendandrenew:automirrorbind:limitandpay:limit: actions within cap proceed autonomously; actions that would exceed it trigger step-up confirmation. - 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.
10. How to conform
What an implementer declares. Consent, Authority and Scopes v0.2, and the autonomy tier it operates at (Tier A or Tier B, Section 6). Conformance composes with Core Patterns vN (Section 9).
Which roles the requirements address. The scope model and the tier requirements address the agent and the intermediation layer jointly: the agent holds and exercises authority, the layer records and enforces it. Section 6.1 reaches the carrier wherever an existing policy is involved.
Testable statements. Each follows from a MUST on this page.
- A
bindexercised whileacknowledge:disclosuresis unsatisfied for that specific quote is refused by the intermediation layer, and the refusal is recorded in the audit ledger with its reason (4.4, Section 8). - A Class 2 or Class 3 action taken by an agent that presented no verifiable identity the intermediation layer trusts is a conformance failure (Section 5).
- A transact or claim action completed over a narrated relay is a conformance failure, whatever authority was held (4.1, Relay-graded authority).
- An
amendorrenew:autoexercise whose premium falls outside the granted cap and which proceeded without step-up confirmation is a conformance failure (4.2, Section 6).
Every grant, every exercise of a scope, every step-up confirmation or pre-authorisation, every revocation and every refused Class 2 or Class 3 action is recoverable from the audit ledger, with its mandate references, its reason where it was refused, and the identity of the agent that acted (Section 8).
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.