Privacy of Payments and Privacy of Requests

Chapter 13 Privacy of Payments and Privacy of Requests Agent networks must reason about two separable privacy surfaces: who paid whom, for what, and when (payment privacy) and what the buyer asked for and what data was sent (request privacy). These are orthogonal: strong payment privacy does not imply confidential prompts, and vice versa. Scrypted’s stack touches both, often in tension with observability and verification. 13.1 Payment privacy 13.1.1 Leakage channels Channel What leaks Public chain settlement Addresses, amounts, tokens, timestamps — visible to anyone with a block explorer. Facilitator / PSP Full payment payload, IP, session correlation. HTTP 402 round-trip Payment requirements, headers, retries. Receipt–body binding MPP Payment-Receipt + Content-Digest links payment to specific request. Internal DB Job ↔ payment ↔ prompt joins. Default USDC-on-Base x402 flows are pseudonymous at best: addresses can be fresh per agent, but graph analysis, facilitator KYC, and HTTP correlation re-identify many deployments. 13.1.2 Privacy mechanisms Fresh EOAs / smart accounts: Break naive address reuse; does not hide amounts or counterparties. Stealth addresses (ERC-5564 + ERC-6538): Hide recipient linkage on-chain. Standardized; requires wallet support. ZK pools (RAILGUN-class): Shield amount and counterparty inside pool rules. Few facilitators accept shielded assets; compliance friction with FATF Travel Rule. Off-chain / TEE settlement: Moves details off the public ledger; trust shifts to TEE operator. Card / PSP rails (MPP Stripe path): Strong privacy vs chain observers; the PSP sees everything. 69

13.1.3 Product tiers (hypothesis) (A) Pseudonymous public stablecoin (default). (B) Facilitator-enforced minimum retention, no content logging. (C) Stealth or ZK settlement where legally viable. (D) Card / PSP rails for buyers prioritizing chain opacity over PSP trust. The network routes per job policy, not a one-size default. 13.2 Request privacy 13.2.1 Leakage channels Channel What leaks TLS-terminated ingress Full prompt, files, headers to platform operator. Provider API calls Prompts to third-party model vendors under their privacy policy. Logs, traces, APM Prompts in application logs; observability traces. Job / workflow DB Step results, attachments in JobExecutionState. CRPC verification Outputs revealed to committee; inputs may be needed for replay. Registry metadata Capability metadata may fingerprint clients via routing patterns. 13.2.2 Mechanisms CPU/GPU TEE inference: Hardware-enforced isolation. NVIDIA Hopper confidential computing, Intel TDX, AMD SEV-SNP. Vendors (Phala, Privatemode, Fortanix) productize confidential inference APIs. Enterprise data controls: Contractual no-retention, modified monitoring (e.g., OpenAI data controls). Legal/operational, not cryptographic. On-device / local inference: Data never leaves device. Poor fit for largest foundation models unless distilled. FHE / MPC: Cryptographic confidentiality. Research / niche for LLM-scale throughput today. Request privacy is most credibly delivered by routing sensitive steps to TEE-backed ingredients with remote attestation published on ERC-8004 validation metadata, combined with self-hosted observability with PII scrubbing, and buyer-chosen providers under zero-data-retention contracts. 13.2.3 Bearer token privacy properties The Scrypted API authenticates via SHA-256-hashed bearer tokens: the database stores only the hash, never the plaintext token. This creates a one-way privacy property: the database cannot reverse a hash to identify who submitted work. At rest, accounts are pseudonymous UUIDs linked to job histories but not to external identities. Linkability is opt-in by the user: reuse the same token and jobs are correlated; use a fresh token per request and they are unlinkable. The user controls the privacy dial. Agent-to-agent 70

delegation inherits this property: an agent can share its token with sub-agents (single billing identity) or issue fresh tokens per sub-agent (isolated billing). The vulnerability: during request processing, the plaintext token is in RAM. Anyone with process access—operator, attacker, subpoena—can observe the token-to-account mapping in real time. 13.2.4 TEE request mixing (opt-in) The mitigation for in-RAM token exposure is a TEE passthrough layer—not a payment mixer, but a request mixer:

1. A Trusted Execution Environment (enabled by EigenCloud TEE attestation) handles bearer token creation. The TEE generates the token, computes the hash, and sends only the hash to the Scrypted database.
2. On each request, the TEE validates the bearer token inside the enclave, strips it, and forwards only the hash or an opaque session identifier to the Scrypted API.
3. The TEE also handles x402 payment proof forwarding, optionally using fresh settlement addresses per request for full payment unlinkability.
4. The Scrypted API processes the job without ever seeing the original token. The enclave’s code is attestable and auditable without revealing runtime state. The distinction from payment mixing matters legally: a payment mixer commingles funds; a request mixer commingles requests. Funds flow transparently on-chain; what is hidden is which request came from which identity. No regulatory review has been conducted on this framing—it is flagged as an open risk. The TEE mixer is opt-in. The current production path is direct AWS API Gateway. Three privacy tiers: (A) direct gateway (current, lowest privacy), (B) TEE mixer opt-in (near-term, full request unlinkability), (C) possible default as TEE infrastructure matures. CRPC connection: Committee members submitting attestations through the TEE mixer have their participation unlinkable to their on-chain identity during the commit phase—directly strengthening collusion resistance. 13.3 Confidential inference: TEE attestation and ERC-8004 Hardware TEE vendors produce remote attestation reports verifiable against vendor certificate chains. Intel DCAP supports quote verification for SGX/TDX evidence. The ERC-8004 Validation Registry’s community-draft data profile includes typed fields for teeAttestation (quote, signature, report data, timestamp) and zkml-proof, signaling intent to unify TEE and cryptographic evidence. Buyer-side verification is local-first: fetch the agent’s validation URI, extract the attestation quote, verify with the appropriate vendor SDK (Intel QVL, NVIDIA attestation), and compare measurements against a recipe-policy allowlist. No single central viewer is required. Long-term, CRPC committees could require both output agreement and a valid TEE quote attached to the validation record — shrinking trust in the operator without exposing prompts. 71

13.4 Tensions Goal Conflicts with Payment privacy CRPC / dispute needs attributable receipts. Resolution: commit receipt hashes + job binding; payer may use fresh addresses or ZK. Request privacy Observability (Langfuse, support tooling). Resolution: self-host + redaction; separate trace tier per job class; TEE evidence on 8004 Validation URIs. Wrapper transparency Hiding the delegation graph. Resolution: disclosure mandates for honest wrap; privacy claims must not re-enable opaque laundering. Open Intents materialization Fingerprinting repeat routes. Resolution: standard access formats minimize client-identifying metadata. PGTR / on-chain receipts Public linkage. Resolution: extends the privacy SWOT to the relay layer. 13.5 CRPC and prompt confidentiality: a staged path Phase What validators see A (now) Outputs or output hashes + metadata; no requirement to ship raw prompts B (next) Committed semantic fingerprints (hash of normalized prompt + salt) for dispute only C (long-term) zkML inference integrity proofs; public inputs include model id, policy hash, output hash — Full LLM zero-knowledge proving at interactive latency is not production-general today. CRPC remains the honest backstop for fuzzy outputs while TEE covers input and weight confidentiality. 13.6 Compliance boundaries FATF guidance on virtual assets requires originator/beneficiary information for inter-VASP transfers above thresholds (the “Travel Rule”). Transparent on-chain USDC between identified facilitators is easier to align with compliance than shielded pool withdrawals. Stealth addresses (ERC-5564) improve counterparty unlinkability on-chain but do not solve VASP KYC obligations — the facilitator may still see payer identity at the custodial boundary. Default: public-chain x402 with contractual data handling. Optional: documented highfriction ZK/stealth paths for self-custodied agents with explicit buyer-responsibility language. Regulated enterprise buyers likely stay on card/PSP (Stripe via MPP) for years. This section is not legal advice. Enterprise defaults to a payment service provider; the network documents options honestly. 72

Source: transcribed from the compiled Scrypted Network Design whitepaper PDF for web reading. Layout, figures, and pagination may differ from the PDF.