Zum Hauptinhalt springen

Documentation Index

Fetch the complete documentation index at: https://docs.getovra.com/llms.txt

Use this file to discover all available pages before exploring further.

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:
  1. Der Autofill-Token trägt keine Card-Data — er ist ein 30-Sekunden-TTL Handle gebunden an (Intent, Card, Merchant-Origin, Max-Amount).
  2. Der Redeem-Endpoint verlangt X-CUA-Harness-Secret, das der Harness-Prozess hält und das LLM nicht.
  3. 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

1

Autofill-Token minten

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

Übergabe an den Harness

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

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.
4

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.
5

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

StatusCodeBedeutung
400E_VALIDATIONBad Body — siehe issues-Array
401E_AUTH_MISSINGKein Auth überhaupt
403E_AFT_INTENT_NOT_APPROVEDIntent nicht approved
403E_AFT_INTENT_AMOUNT_MISMATCHamountCentsMax ≠ Intent-Max
403E_AFT_CARD_INACTIVEKarte ist frozen, terminated oder falscher Agent
404E_AFT_NOT_FOUNDToken nicht gefunden, Intent fehlt oder Karte fehlt
410E_AFT_EXPIREDTTL abgelaufen
410E_AFT_REPLAYBereits 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.