PII redaction proxy for outbound webhooks

The idea

Most SaaS backends fire webhooks and outbound API calls to a dozen third parties: analytics, support tools, CRMs, Slack, email providers. Almost none of them audit what's actually in those payloads. This is a self-hosted proxy that intercepts outbound HTTP calls, matches known PII patterns and configurable field paths, redacts or tokenizes them in place, and forwards the cleaned payload — with a log of what was removed and why.

Why build this

Compliance teams at mid-size companies increasingly get asked "can you prove customer SSNs never left our network toward Vendor X?" and the honest answer is usually "we hope not." Engineers bolt PII scrubbing onto individual integrations ad hoc, if at all, and it drifts out of sync as payloads change. A proxy-layer solution decouples redaction policy from application code: developers point webhook URLs at the proxy instead of the vendor directly, and policy changes don't require a deploy. This matters more now because DPAs (data processing agreements) and SOC 2 audits increasingly ask for evidence of outbound data controls, not just inbound ones, and privacy regulations (GDPR, CCPA, sector rules like HIPAA) put liability on the sender regardless of what the receiving vendor does with the data.

Stack sketch

• Proxy core: Go or Rust for low-latency request interception (a thin reverse-proxy service, not a full mesh sidecar)
• Redaction engine: regex + Presidio-style NER for detecting emails, SSNs, credit cards, phone numbers, plus a config file for custom field-path rules (e.g. $.customer.tax_id) per destination
• Config store: YAML/JSON policy files per outbound destination, checked into the customer's own repo, loaded at startup with hot reload
• Audit log: append-only log (Postgres or plain JSON lines) recording what was redacted, when, and for which destination — never the raw value itself
• Tokenization option: reversible format-preserving tokenization backed by a local key, for cases where the receiving vendor needs a stable pseudonymous identifier
• Deployment: single Docker container, deployed as a sidecar or a standalone egress proxy; works with any HTTP client via HTTPS_PROXY env var or explicit base-URL rewriting
• Dashboard: minimal web UI for viewing recent redaction events and editing policy files, backed by the same config store

Scope for v1

• Support explicit destination allowlist: proxy only forwards to configured hostnames, blocking anything not on the list
• Built-in detectors for the most common PII types: email, phone, SSN/national ID, credit card, IP address
• Custom field-path redaction rules per destination, defined in a simple YAML policy file
• Redact-in-place mode only (replace with [REDACTED:email]); tokenization is a stretch goal, not required for v1
• Audit log viewable via CLI (proxy audit tail --destination=slack) — no dashboard yet
• Out of scope for v1: multi-tenant SaaS hosting, automatic policy inference from traffic, non-HTTP protocols (gRPC, message queues)

Where it could go

Once the redaction core is solid, the natural next step is policy inference: watch real outbound traffic in a dry-run "log only" mode, cluster field paths that look like PII but aren't yet covered by a rule, and suggest policy additions to the compliance team. That turns the tool from purely reactive into something that catches new integrations before anyone has to remember to configure them.

The second expansion path is inbound symmetry: the same detection engine applied to inbound webhook payloads (e.g., from Stripe or a support tool) to flag when a vendor is sending you more PII than your data processing agreement expects, which is a real and under-tooled problem for companies receiving third-party data.

Watch out for

False negatives are the entire risk surface here — a regex-only detector will miss enough real PII that teams over-trust the tool and stop doing manual review, so the pitch has to be "an additional control," not "the control." Latency also matters: this sits in the hot path of every outbound call, so redaction has to run in single-digit milliseconds or teams will bypass it under load.