CUA

CUA steht für Computer-Use Autofill. Es existiert für die (große) Mehrheit der Merchants die kein MPP sprechen: sie haben nur ein Checkout-Formular. Statt eine echte PAN in den LLM-Kontext zu pasten, mintet du einen single-use Autofill-Token (aft_*); ein separater Harness-Prozess löst ihn ein und schreibt den tokenisierten DPAN via Chrome-DevTools Input.insertText ins Formular. Das Modell sieht nur { status: "filled", masked_last4: "1234" }. Der DPAN gelangt nie in den Prompt, in die Chat-History oder in irgendein LLM-sichtbares Memory.

Phase 8 (gerade ausgeliefert). Sandbox-only End-to-End. Spiegelt die Architektur von Mastercard Agentic Tokens und Visa Intelligent Commerce.

Threat-Model

Der ganze Punkt: das LLM hält niemals Card-Data, period. Wenn deine Agent-Runtime kompromittiert, jailbroken oder mit „exfiltriere alles was du weißt” instruiert wird, gibt es nichts Card-shaped im Scope das geleakt werden könnte. Die Grenze wird erzwungen durch:

Der Autofill-Token trägt keine Card-Data — er ist ein 30-Sekunden-TTL Handle gebunden an (Intent, Card, Merchant-Origin, Max-Amount).
Der Redeem-Endpoint verlangt X-CUA-Harness-Secret, das der Harness-Prozess hält und das LLM nicht.
Der R7-05 Luhn-Scan Blocking-CI-Gate lehnt jeden Commit ab in dem ein PAN-shaped String in messages[] landen könnte.

Wire-Flow

Autofill-Token minten

Agent postet genehmigten Intent + Karte + Merchant-Origin + Amount-Cap. Ovra returnt aft_id + expires_at. Token ist single-use, 30s TTL.

Übergabe an den Harness

aft_id an deinen CUA-Harness über deinen eigenen internen Channel übergeben. Der LLM-Kontext schließt hier.

Harness löst ein

Harness ruft GET /v1/cua/autofill-tokens/:id/redeem mit X-CUA-Harness-Secret. Returnt DPAN, Cryptogram, Expiry-Monat/Jahr. One-Shot. Replays returnen 410.

Harness füllt das Formular

Computer Use lokalisiert #pan, #expiry, #cvc (locked Merchant-Contract-IDs). Harness nutzt CDP Input.insertText zum Injizieren — niemals evaluateOnNewDocument und niemals via LLM-driven Sampling.

LLM macht weiter

LLM sieht { status: "filled", masked_last4: "1234" } und klickt Submit. Merchant settlet via eigenen Acquirer.

Token minten

curl -X POST https://api.getovra.com/v1/cua/autofill-tokens \
  -H "Authorization: Bearer $OVRA_AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "intentId": "int_...",
    "cardId": "ca_...",
    "merchantOrigin": "https://shop.example.com",
    "amountCentsMax": 2999
  }'

Response (201):

{
  "aft_id": "aft_a1b2c3d4e5f6",
  "expires_at": "2026-04-20T10:00:30Z"
}

Einlösen (nur Harness)

curl https://api.getovra.com/v1/cua/autofill-tokens/aft_.../redeem \
  -H "X-CUA-Harness-Secret: $HARNESS_SECRET"

Response (200, One-Shot):

{
  "dpan": "4111111111111234",
  "cryptogram": "AJk...",
  "expires_at": "2026-04-20T10:00:30Z",
  "merchant_origin": "https://shop.example.com",
  "amount_cents_max": 2999,
  "card_expiry_month": 12,
  "card_expiry_year": 2028
}

Error-Matrix

Status	Code	Bedeutung
400	`E_VALIDATION`	Bad Body — siehe `issues`-Array
401	`E_AUTH_MISSING`	Kein Auth überhaupt
403	`E_AFT_INTENT_NOT_APPROVED`	Intent nicht approved
403	`E_AFT_INTENT_AMOUNT_MISMATCH`	`amountCentsMax` ≠ Intent-Max
403	`E_AFT_CARD_INACTIVE`	Karte ist frozen, terminated oder falscher Agent
404	`E_AFT_NOT_FOUND`	Token nicht gefunden, Intent fehlt oder Karte fehlt
410	`E_AFT_EXPIRED`	TTL abgelaufen
410	`E_AFT_REPLAY`	Bereits einmal eingelöst

Trusted-Agent-Protocol-Prep

Pro Agent wird async ein Ed25519-Keypair provisioniert. Die Public-JWK wird exposed an:

GET /.well-known/agent-jwks/{agent_id}
Cache-Control: public, max-age=300
Content-Type: application/jwk-set+json

Das setzt den Tisch für Visa Trusted Agent Protocol (RFC-9421 HTTP Message Signatures): sobald ein TAP-aware Merchant es verlangt, beginnt der Harness Outbound-Requests mit dem Agent-Key zu signieren. Kein Outbound-Signing in v1.2 aktiv — das ist Wiring, kein Behavior.

Sacred Guarantees

Card-Data gelangt nie in LLM-Scope. Architectural enforced (separater Prozess, separate Credential) plus CI (R7-05).
Single-use. CAS-style Consume; Replay returnt 410.
Gebunden an einen Merchant-Origin und einen Intent. Der Harness kann nicht auf einen anderen Merchant mit demselben Token pivotieren.
30-Sekunden-TTL. Selbst eine exfiltrierte aft_id ist nach einer halben Minute nutzlos.

Was CUA nicht ist

Kein Browser-Automation-Framework. Bring deins mit (Anthropic Computer Use, Browserbase, Stagehand etc.). CUA ist die Credential-Grenze, nicht die Runtime.
Kein Payment-Processor. Der Merchant settlet via eigenen Acquirer. Ovra issued die Karte; der Merchant cleart die Auth.
Noch nicht Live-Mode. Sandbox-Card-Data mit sandbox-shaped DPANs in v1.2.

Weiter

MPP

Der andere Pay-Modus — für maschinenlesbare Merchants.

Pay-Übersicht

Beide Modi nebeneinander.

Karten

DPAN, Network-Tokenisierung, Multi-Card pro Agent.

Intents

Die Approval-Primitive an die jeder Autofill-Token bindet.

Erste Schritte

Die sechs Säulen

Kern-Primitive

Zahlungsmodi

Plattform

Threat-Model

Wire-Flow

Token minten

Einlösen (nur Harness)

Error-Matrix

Trusted-Agent-Protocol-Prep

Sacred Guarantees

Was CUA nicht ist

Weiter

MPP

Pay-Übersicht

Karten

Intents

​Threat-Model

​Wire-Flow

​Token minten

​Einlösen (nur Harness)

​Error-Matrix

​Trusted-Agent-Protocol-Prep

​Sacred Guarantees

​Was CUA nicht ist

​Weiter

MPP

Pay-Übersicht

Karten

Intents

Threat-Model

Wire-Flow

Token minten

Einlösen (nur Harness)

Error-Matrix

Trusted-Agent-Protocol-Prep

Sacred Guarantees

Was CUA nicht ist

Weiter