[Use Case] A seller checks the paying agent's attested software and its user's spending authority before starting paid work

fg-tida-use-cases-use-case-a-seller-checks-the-paying-agents-attested-software-and-its-users-spending-authority-before-starting-paid-work-67

TypeFG-TIDA document
GroupTrust and Identity for Humans and Agentic AI
StateSubmitted
AuthorsNot entered
Last updated2026-10-23 15:11 UTC

Formats and resources

External reference

Use cases

Abstract

@debora-com: following the GitHub process described on the 30 September and 14 October calls, this is a use case on what a seller checks before it commits paid work for an AI agent. It is offered as input to Annex A.1.3 of the Terms of Reference (payment use cases) and bears on Annex A.2.2's evidence criteria for continuous trust evaluation. Requirement numbers refer to Section 5, and the supporting note states each requirement in full, with a glossary.

In one page

What happens. An AI agent buys services for a user within set limits, and a seller that commits work bears that cost if the payment is reversed.

The decision. May this seller commit £15 of an expert's time on this agent's payment?

Why the paying build matters. Two builds of the agent pay under one user authority (the issuer-signed grant naming the keys allowed to pay), with the same card and valid signatures. One repeats its purchase identifier on every retry; the other makes a new one for each attempt. If a reply is lost, the second build retries under a new identifier and buys the same answer twice: a second charge and a second expert task that the seller's record treats as a separate purchase. Here, only the attestation result (a verifier's signed report on the paying agent's model, code, tool set and policy) tells the seller which build was launched and measured, so the seller can accept the first and refuse the second. It says nothing about either build's correctness.

What the case asks of FG-TIDA. Assess the requirements this payment case exposes and name the liaison questions. It gives theme 22's open question "When to attest?" a concrete case: the seller's commitment of the task is the consequential action.

What depends on other bodies. Card networks, EMVCo and issuers would need to carry the purchase identifier to the issuer, refuse a second payment per purchase, reserve against the weekly limit on every approval path and report the approved card account to the seller. The payment protocols' authors would need to say where the result, signature and authority travel: the Machine Payments Protocol's card method has no field for them, and its core draft guarantees only that servers accept credentials of at least 4KB. The issuer applies the UK low-value exemption from strong customer authentication; after at most six £15 payments in a row it runs out, and the next payment waits for the user.

What this base case does not catch (Section 2). The agent's code, tool set and policy are measured once, when the instance starts, so a change made after that goes unseen; the case records that gap. The age limit set by the amount paid therefore applies to the evidence itself, and reaches the state the evidence describes only where a fresh instance is started for each purchase or the software is measured while it runs. Which model the agent calls cannot yet be checked on real evidence, so the tests simulate that claim and say so.

1. Identification

Title: A seller checks the paying agent's attested software and its user's spending authority before starting paid work
Submitting organization: True Primary
Contact name: King Yew Choo
Contact email: k.choo@trueprimary.com

Sector:
- [ ] Education
- [ ] Displaced persons / humanitarian
- [ ] Health
- [x] Financial services
- [ ] Telecom
- [ ] Media and publishing
- [ ] Logistics
- [ ] Energy
- [ ] Critical infrastructure
- [ ] Smart home / IoT
- [x] Other (specify): paid APIs and machine-to-machine commerce over HTTP

2. The situation

Plain language description:

A user lets one AI agent buy services within limits of £20 a purchase and £100 a week, each purchase a paid web request. A seller that has started the work bears its cost if the payment is reversed later. Today the seller can check the payment, and under some of the payment protocols and card programmes compared in Section 7 also what the user allowed and which registered agent is paying; none of them gives it evidence of which software the paying agent runs.

Actor:

  • The user, who sets the limits.
  • The issuer, the user's payment provider, which issues the agent's card credential and approves payments.
  • The agent instance, its deployer and its developer. An instance is one running copy of the agent in an environment its platform isolates in hardware and measures, such as an enclave or a confidential virtual machine; agents that share one environment share its key and its result.
  • The platform and its vendor, a verifier that checks evidence and issues attestation results, and the hosted model's provider.
  • The payee (the seller), its payment provider and the expert whose time it sells.
  • The card network and the two enablers of the Machine Payments Protocol's card method, which supply and process the card credential.

Action:

This hypothetical base case adds checks to that card method, where the payee answers a request with an HTTP 402 payment challenge and the agent pays with a payment credential. The issuer has bound the user's card account (named by its payment account reference) to a key that, by an attestation result, only this instance holds. That signed binding is the authority. It also carries the user's limits: £20 a purchase, UK online sellers, 3 months. The issuer itself holds the £100 weekly limit. In order:

  1. The agent asks for a £15 answer under a purchase identifier it repeats on every retry (requirement 3).
  2. The payee replies with a challenge naming the verifiers it accepts (requirement 8).
  3. The agent obtains an attestation result on evidence signed after the challenge, then signs challenge, purchase identifier and authority reference with its instance key (requirement 2).
  4. The agent pays with a payment credential, the authority, the result and the signature (requirement 1).
  5. The payee checks all four, then records the purchase before the payment is processed (requirement 4).
  6. The issuer reserves £15 against the week's £100 as it approves, which it can do alone for its own approvals. It can also refuse a second payment once the card networks carry the purchase identifier to it (requirement 7).
  7. The payee compares the authority's card account with the one the approval reports, a report the card method does not yet carry (requirement 7). A missing report or a mismatch voids or refunds the payment (requirement 5).
  8. The payee rechecks freshness and authority validity, records the task's start, then dispatches it (requirements 6 and 4).

If any check fails, no task starts.

Decision required:

May this payee commit £15 of an expert's time on this agent's payment?

Problem encountered:

  1. The payment protocols and card programmes compared define no evidence of the paying instance's software state (Mastercard's Verifiable Intent reserves a claim for it and defines no scheme), so a registered agent can pay while running a changed model, code, tool set or policy. The card method does not specify forwarding the task details to the issuer, so the check sits with the seller (the note, Section 2).
  2. A result appraises evidence signed earlier, and the claim values inside it can be older than that signature. The state "might change immediately after the Evidence or Attestation Result was generated" (RFC 9334, section 10), so a payee can commit on a changed state.

Current mitigation:

Registered agent keys identify the paying agent, and issuer, token and consent limits cap spending. On Visa cards a card-absent fraud dispute (condition 10.4) is invalid when the authorisation carries confirmed 3-D Secure or token authentication data. Both problems stay open (the note, Section 2).

Residual gap:

None of the texts the note compares defines:

  1. Semantics: which claims about the agent a payee can require, from which sources and against which reference values.
  2. Profile and carriage: how those claims bind to the challenge, the purchase, the authority and the card account, how a hosted model provider's evidence reaches the payee's result tied to the instance's own call, and how the purchase identifier reaches a consumer card's issuer.
  3. Local policy: an evidence age set by amount, and which mechanism a payee requires to catch a later change.
  4. Deployment trust (no requirement set): who publishes an agent's reference values to a verifier new to the payee, how that payee finds verifiers, which verifiers the issuer relies on, and how a payee obtains the key the issuer signs authorities with.
  5. Regulation: where strong customer authentication sits in an agent's series of payments (the case's reading is in the note, Section 3).

3. Actors and context

Taxonomy roles involved:
- [x] Principal — possesses the authority being exercised; source of the mandate (here: the user)
- [x] Relying party — must decide whether to accept the agent's authority (here: the payee, as RATS Relying Party; the issuer, when it binds the card credential to the instance key)
- [x] Builder: the agent's developer (Reference Value Provider in RATS, the IETF's remote attestation architecture, RFC 9334)
- [x] Deployer / Owner: runs the agent and publishes reference values for its tool set and policy
- [x] Agent instance: the RATS target environment
- [x] User — interacts with the agent; may or may not be the principal (here: the principal)
- [x] Infra provider: the card network, the card method's enablers, the platform vendor (RATS Endorser) and the hosted model's provider (RATS Attester)
- [x] Attestor: the platform's attesting environment
- [x] Other (specify): the verifier (RATS Verifier)

Mandates in this case:

Grantor Grantee What is conferred Governing regime
The user The agent instance, through its deployer Authority to buy services within the limits, under the deployer's declared policy United Kingdom: the contract with the deployer; consumer law
The user The issuer Consent to a series of payments by the named agent instance, and spending limits the issuer enforces (requirement 5) United Kingdom: Payment Services Regulations 2017, regulations 67, 71 and 83

Strong customer authentication (regulation 100 of the Payment Services Regulations 2017) applies to payments the payer initiates, and this case reads the agent's payment as one. The base case relies on Article 16 of the FCA's technical standards on strong customer authentication, the low-value exemption, which the issuer applies. The user also authenticates when the authority is bound to the instance key (requirement 11; the note, Section 3).

Cross-border?
- [ ] Yes — jurisdictions involved:
- [x] No

The payment, user, issuer and payee are in the United Kingdom; the card network, verifier, platform vendor and model provider may sit elsewhere, and no requirement depends on where.

Embodied (physical actuation or sensing)?
- [ ] Yes — physical context:
- [x] No

Agent action type:
- [ ] Read-only
- [x] Consequential (reversible)
- [x] Irreversible

Crosses organisational boundary?
- [x] Yes (specify): the user, issuer, payee and platform vendor are separate parties.
- [ ] No

Risk level:
- [ ] Low
- [x] Medium
- [ ] High

Medium: issuer limits and requirement 7's reservation cap what the issuer approves, though a missed duplicate, a late capture or a refund that frees the weekly limit again can pass them. The payee risks one task's cost per purchase plus a dispute fee.

4. Theme relevance

Theme Yes Primary Justification (required if checked)
Dynamic Identity [x] [ ] The agent's software can change between payments, and a restarted instance can pay under a new key (requirement 2).
Continuous Trust and Attestation [x] [x] The payee requires an attestation result at each payment, one answer to theme 22's "When to attest?". Amount and the declared change-catching mechanism decide when an earlier result can be reused (requirement 6).
Delegation [x] [ ] The user's spending authority is bound to the attested instance key (requirement 5).
Discovery and Cross-Border Trust [x] [ ] The payee chooses its verifiers in advance (requirement 8); how a new seller finds them stays open (residual gap 4).
Runtime Enforcement (Control Plane) [x] [ ] The payee's gate and its one record per purchase sit at its boundary (requirement 4).
Embodied AI Identity and Trust [ ] [ ] Not exercised.

Related theme proposals:

5. Requirements

Rows 1 to 8 state the outcome a deployment (an implementation put to the Section 6 tests) must show, or in requirement 7 the issuer and the card network; the supporting note, Section 5, states each in full. Must marks what the case needs, whether or not any text read shows it met today.

# Type (choose one) Requirement description Criticality (choose one)
1 Technical At each payment the payee requires an attestation result about the paying instance from a verifier it chose in advance, with each claim naming its source (note 1.1 to 1.6). Must
2 Technical The result names a key only this instance can use, and the instance signs the challenge, purchase identifier and authority reference with it, through the component its code measurement covers, after its own checks on the purchase. A deployment that shows only where the key is held claims only that (note 2). Must
3 Technical A purchase is the payee plus a random identifier the instance repeats on every retry, and a later request that changes any recorded field is refused (note 3). Must
4 Technical One record per purchase lets one task start and one payment stand, and a replacement request is allowed only before the task starts. After a recorded start, the payment is voided or refunded only once the recipient (the component that begins the work) confirms, or that record shows, that no task began or will begin (note 4.1 to 4.6). Must
5 Technical The user's authority, signed by the issuer, names the instance key, the card account and the scope, and the payee checks the card account the approval reports against it (note 5.1 to 5.5). Must
6 Technical A freshness rule set by the amount bounds how old the evidence and the result may be, in a stated unit and clock. For a claim older than its signature, the rule names what would catch a change, or records the interval in which a change goes unseen (note 6.1 to 6.6). Must
7 Technical An issuer can reserve the amount against the user's weekly limit by itself, in one atomic step with its approval, so concurrent purchases cannot share one unspent limit. The rest needs the card networks. They would carry the purchase identifier to the issuer, keep one payment in force (approved, captured, settled or of unknown outcome) per purchase, have every approval path reserve or decline (the network approving in the issuer's place and a processor approving on a timeout included) and check duplicates where the identifier arrives, and report the approved card account to the payee (note 7.1 to 7.4). Must
8 Technical The payee accepts results only from verifiers it chose in advance and names in its challenge; a missing, untrusted, stale or mismatched result means no task starts (note 8). Must
9 Business A payee that calls a verifier needs at most one appraisal per instance while a result may be reused, forced refreshes counted separately; one that receives the result in the payment calls none (note 9). Should
10 Business For each purchase the payee keeps what shows who authorised a disputed payment, and the deployment states its retention, retrieval and disclosure rules (note 10.1 to 10.3). Should
11 Legal Each payment meets the strong customer authentication rules in force; in the base case the low-value exemption covers at most six £15 payments in a row, and the next waits for the user (note 11.1 to 11.3). Must
12 Business A task that cannot start is voided or refunded, and each void, refund or return stays open until the provider confirms it; a refund blocked by an open dispute waits for the dispute to close (note 12). Must
13 Business Where a payment method moves money before the payee decides, the payee returns every payment it does not fulfil by a route it names; a method where neither it nor the payee offers a return route is not covered (note 13). Must

6. Assessment criteria

Success criteria: In the base case, once the payment is authenticated under requirement 11, one £15 purchase within the user's authority yields one task and one payment in force, however often its request arrives while the record is kept. It still yields one payment in force if the payee's record fails and requirement 7 applies (the identifier reaching an issuer, real or simulated). Approvals, captures and debits are counted apart, and a capture or debit beyond the payment in force, where the run observes it, stays open until repaid. From an accepted build, two deliberate purchases of the same answer under two purchase identifiers yield two tasks and two payments. The summary's build pair is told apart by the attestation check alone.

Measurable metric: Counted against targets:

  • duplicate tasks per purchase: 0;
  • tasks started after the payee closed the purchase as not started: 0;
  • charges whose task did not start: all tracked until the provider confirms, open ones reported by amount and age and never counted as repaid;
  • charges for requests refused before payment: 0;
  • change in 95th-percentile time per completed purchase from a run without the checks, with user-authentication waits shown apart, against a target declared before the run.

A run that claims a freshness pass declares a maximum age for each required claim before it starts and refuses older or undated values. The base case bounds the evidence's age, records each claim value's age and claims no freshness pass. Simulated parts are marked. A later stage pairs verifiers and payee-side checkers built by different teams, with expected results written down before the run, valid results accepted and invalid ones refused in every pairing. Nothing has been run.

7. Duplication check

Existing standards or SDOs:

Ten groups are compared in the supporting note, Section 7: ITU-T SG17; IETF RATS; IETF key binding and workload attestation; agent and model evidence drafts; attested payment authorisation; execution finality; the Action Evidence Boundary; Visa, Mastercard and EMVCo; the Machine Payments Protocol, x402, AP2 and the Agentic Commerce Protocol; and the author's own draft and paper. That draft and paper gate a paid task on payment or entitlement before fulfilment; this case adds the paying agent's state as an input and places the reservation at the issuer.

Overlap notes:

  • Scope: the Terms of Reference put agentic AI protocols out of scope, and the card method is used only to make the requirements testable on one rail. The record the payee writes before payment needs a profile of the core draft, which bars side effects for unpaid requests.
  • Left open: three things appear in none of the texts read. One, for card networks to specify, is card-rail carriage of a purchase identifier that survives a fresh challenge and reaches the issuer of a consumer card. Another, a local policy choice, is an evidence age set by the amount paid. RFC 9334, section 10, leaves that to each relying party's appraisal policy. The payment-finality draft, section 14.2, comes closest: it lets an earlier evaluation be reused inside an envelope with a maximum amount and an expiry, for authorisation checks, and sets no age for attestation evidence. The 30 September minutes already list risk-keyed freshness among theme 22's integration questions. The third, for issuers and card networks to specify, is the issuer booking each approval against a user-set weekly limit in one atomic step, so concurrent purchases cannot draw on the same remaining limit. Verifiable Intent requires payment networks to check a mandate's cumulative budget at authorisation without saying the check and the booking are one step; the attested-payment draft and the author's own draft bound spending atomically elsewhere, at the payment executor and at the gate.
  • Not read: the SG17 and EMVCo entries rest on summaries and titles, the Visa Intelligent Commerce specifications were not read, and TCG, GlobalPlatform, Web Bot Auth and the SCITT and x402 working-group deliverables are not compared. One liaison question for SG17: does X.aiidm, XSTR.athena, X.aplm-aia or the proposed XSTR.caars cover a payee's check of an agent's measured state before it commits paid work?
  • Other filed cases: of the 19 use cases filed by 19 October 2026 (two since closed; pull requests share their numbering), #5, #7 and #12 bind evidence to a model, an execution or an action. #13, #21 and #24 gate a refund, payment or purchase on policy or authority. #9 traces a payment grant without asking for attestation of the agent. #28 reconstructs an unattended agent's actions afterwards. #33 (19 October) binds derived authority to the issuing agent's instance and version (system, model, configuration) and suspends it down the chain after a model update. None makes the paying agent's attested state a condition of the payee committing paid work.

8. Maturity

Pilot status:

  • [x] Hypothetical
  • [ ] Pilot in progress
  • [ ] Deployed in production

Reference implementation: n/a. The base case's service, an expert's answer sold per request, is True Primary's own.

9. IP and confidentiality

Confidentiality level:

  • [x] Public
  • [ ] FG-internal only
  • [ ] Redact before publication

IP notes: None.

10. Assets

Link to assets:
- [ ] Dataset
- [ ] Code
- [ ] Protocol
- [x] Other: Internet-Draft (work in progress), "A Server-Side Model for Gating Agent-Initiated Human-Sourced Asynchronous HTTP Tasks on Payment or Entitlement", revision 01, https://datatracker.ietf.org/doc/draft-king-yew-choo-agentic-payments/01/; working paper, version 2.9, https://doi.org/10.2139/ssrn.7543686; open copy at https://kingyewchoo.co.uk/research/payment-and-entitlement-gate/

IP notes: None.

Revisions

  • No file revisions have been uploaded.