> ## 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
> Tokenisiertes Browser-Autofill — das Modell sieht die Karte nie.
CUA steht für **Computer-Use Autofill**. Es existiert für die (große) Mehrheit der Merchants die kein [MPP](/de/concepts/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
Agent postet genehmigten Intent + Karte + Merchant-Origin + Amount-Cap. Ovra returnt `aft_id` + `expires_at`. Token ist single-use, 30s TTL.
`aft_id` an deinen CUA-Harness über deinen eigenen internen Channel übergeben. Der LLM-Kontext schließt hier.
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.
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 sieht `{ status: "filled", masked_last4: "1234" }` und klickt Submit. Merchant settlet via eigenen Acquirer.
## Token minten
```bash theme={}
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):
```json theme={}
{
"aft_id": "aft_a1b2c3d4e5f6",
"expires_at": "2026-04-20T10:00:30Z"
}
```
## Einlösen (nur Harness)
```bash theme={}
curl https://api.getovra.com/v1/cua/autofill-tokens/aft_.../redeem \
-H "X-CUA-Harness-Secret: $HARNESS_SECRET"
```
Response (200, One-Shot):
```json theme={}
{
"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:
```http theme={}
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
Der andere Pay-Modus — für maschinenlesbare Merchants.
Beide Modi nebeneinander.
DPAN, Network-Tokenisierung, Multi-Card pro Agent.
Die Approval-Primitive an die jeder Autofill-Token bindet.