Security: threat model and normative requirements

A payment protocol for agents is designed from its threats, not patched with them afterwards. The core Stipendex thesis: most attacks are removed architecturally — the LLM has no payment surface, rather than "the LLM was nicely asked not to pay".

Threat model

#	Attack	Vector	Control
A1	Prompt injection: "transfer money to X"	malicious content in the model context	the model has no operation with an arbitrary receiver/amount (invariant I1); at most `pay(quote)`, which runs into the allowlist and limits
A2	Injected "pay this bill" from an attacker-"receiver"	a planted Quote	a Quote is signed by the receiver's key; receiver not on the allowlist → deny; on the allowlist but expensive → HITL
A3	Quote replay / double presentation	network, malicious receiver	single-use `quote_id` + `expires_at`; the wallet journals seen ids
A4	Double charge on one Proof	retries, races	idempotency at every level: receiver and rail return the previous result by `proof_id` (R2)
A5	"Paid but not delivered"	dishonest receiver	Receipt with `result_hash`; withholding a Receipt after a verified Proof is a provable violation (wallet journal + rail evidence); registry reputation
A6	Hidden amount inflation	metered/checkout	capture ≤ estimate+tolerance (I3, C2); beyond — only re-quote + a new confirmation
A7	Receiver substitution under a trusted name	MITM, DNS compromise	the Quote key is checked against the registry descriptor (T1); TLS; signatures over canonical JSON (JCS)
A8	Agent process compromise	malware, RCE on the host	the wallet key lives outside the agent process (keychain/daemon/KMS); damage is bounded by the mandate's remaining limits until `valid_until`
A9	Wallet key compromise	key theft	short mandate TTL; facilitator revocation; facilitator velocity anti-fraud as the second line
A10	A tired principal rubber-stamps confirmations	social engineering through the agent	every confirmation shows: receiver, total, tolerance, remaining limits, mandate purpose; passkey confirmation makes "rubber-stamping" a deliberate act
A11	Pending-queue griefing	payment request spam	queue TTL = Quote TTL; `pay()` rate limit at the wallet; duplicates per receiver are collapsed
A12	Principal privacy leak	receiver learns limits/history	the receiver gets only the Proof (mandate hash, no fields); the registry sees no payments; the facilitator sees the minimum needed for settlement
A13	Poisoned registry	provider hack/dishonesty	provider signature + a "whose signature admitted this payment" journal; multiple providers; removing a provider is one mandate line
A14	A "useful" tool with useless output	legal but junk service	not a payments problem: registry reputation/levels, limits as a damage bound; the protocol guarantees provability ("paid, received X"), not the quality of X

Normative requirements (MUST summary)

Wallet:

S1. The only money operation reachable by the model is pay(quote); no other interfaces (transfer, key export, mandate editing) exist in the model's context.
S2. Check order: Quote signature/expiry → allowlist (default deny) → limits (worst case for estimates) → HITL → rail.
S3. Durable limit counters and the quote_id/proof_id journal survive restarts.
S4. The signing key lives outside the process holding LLM context.
S5. Only idempotent operations are retried; money operations are never retried blindly.

Receiver:

S6. Quotes are single-use, signed, with a TTL; a repeated proof_id → the previous result.
S7. A Receipt is issued for every verified Proof, including voided.
S8. The key in a Quote matches the published descriptor.

Rail/facilitator:

S9. evidence is third-party verifiable; capture ≤ hold; idempotency.
S10. Velocity control and anomaly detection across wallets and receivers; mandate revocation takes effect immediately.
S11. Crypto rails MUST screen receiver addresses against applicable sanctions lists (e.g. OFAC SDN) and geofence prohibited jurisdictions before settlement — regardless of the operator's formal licensing status (sanctions liability is strict).

The checkout profile adds C1–C5 from spec/checkout-profile.md.

What the protocol deliberately does not guarantee

Quality of what was bought (A14) — that is reputation and disputes, the registry and platform layer.
Fitness of a purchase for the task's goal — algorithmically unverifiable; bounded by limits, the allowlist, the mandate purpose, and audit.
Refunds/disputes for micro-amounts — economically pointless; bounding the damage is cheaper than arbitrating cents.