prxy.monster / security

Security

prxy.monster is the control and receipt layer for AI calls. The interesting boundary is the wire: requests that arrive at api.prxy.monster run through the configured module pipeline, hit the upstream provider, and return with a signed Ed25519 receipt. This page describes what we store, what we sign, and how you control both.

Defaults that matter

hash_only is the default for payload capture. The four canonical sha-256 hashes (client request, provider request, provider response, client response) live on the receipt. Plaintext request and response bodies do not persist by default.
encrypted_at_rest is opt-in per api_key, sealed under a customer-held X25519 public key. Algorithm x25519-xchacha20-poly1305-v1 with per-call ephemeral keys. The customer decrypts client-side; prxy never holds the customer private key.
none is available for compliance opt-out — nothing beyond the receipt hashes persists. Cache is bypassed.
Outcome notes are sha-256 hashed server-side at write time. Raw text never persists; reviewers see only the hash.
Bare anonymous-sandbox tokens never persist at rest. Only anon_key_hash, ip_hash, and counters.
BYOK provider keys are encrypted at rest in user_provider_keys and never returned in plaintext after registration.
Local mode (prxy-monster-local, MIT) has no hosted sync or telemetry. State stays on your hardware.

Receipts and verification

Every routed call returns three response headers — Payment-Receipt, Payment-Receipt-Digest (RFC 9530), and Payment-Receipt-Kid. The receipt body is JCS-canonicalized (RFC 8785 + Unicode NFC) and signed with Ed25519. Public JWKS at /.well-known/prxy-receipt-keys.json. Active key id today: prxy-receipt-2026-q2.

Three live verifier surfaces, all running the same canonicalize-and-verify path: prxy-cli receipt verify <id>, the lair browser verifier at lair.prxy.monster/dashboard/verify, and the <VerifyBadge> on every public receipt page.

Defense in depth

Sentry beforeSend + beforeBreadcrumb strip request/response bodies and sensitive headers (authorization, cookie, x-provider-key, x-api-key) from outbound events.
The 4 canonical hashes detect replay independent of the body.
Encrypted-at-rest payload mode bypasses cache, because we cannot key across customers without seeing the plaintext.
Per-project budgets emit a signed blocked receipt when hard_fail rejects a call — the audit trail covers refusals as well as success.
The gateway runs on AWS App Runner in us-east-1; data-at-rest in the managed Postgres + Upstash Redis is encrypted by the platform.

What we do not

No foundation-model training on customer requests, completions, or outcome notes.

No selling of customer data to third parties.

No silent retention of plaintext request or response bodies.

No retention of bare anonymous-sandbox tokens — only hashes and counters.

No telemetry from prxy-monster-local. Local is local.

Reporting a vulnerability

Email [email protected]. See /.well-known/security.txt for current contact, scope, and PGP key.

Data retention matrix — row-by-row breakdown.
Privacy — what we do and don't do with your data.
Payload capture concept — encryption envelope details.
Receipts concept — schema, visibility levels, signing.