Keep secrets out of LLM traffic

Your engineers paste connection strings into chat. Your agents read config files into context. Either way, secrets end up in requests to an LLM provider — logged, cached, and outside your trust boundary. The fix is a proxy that owns the payload.

The mental model

SCRUBR is a forward proxy with one loop:

1. Mask — scan the outbound request; replace every detected secret with an opaque, HMAC-authenticated sentinel. The mapping stays in an encrypted session vault on your side.
2. Forward — the provider receives structure without substance. The model reasons about «token:a1b2» exactly as well as it would about your real AWS key — better, actually: it can't leak what it never saw.
3. Rehydrate — the response streams back; sentinels are restored to real values on the fly, even when a placeholder is split across SSE chunks. Your user sees a fully reconstituted answer.

Getting to enforcing, honestly

Start in dry-run: SCRUBR reports what it would mask on live traffic without changing anything. That report is your coverage conversation — the curated ruleset already recognizes the major token families (AWS, GCP, GitHub, Slack, Stripe, OpenAI, Anthropic, JWTs, PEM keys), and glossary rules cover the secrets only your organization knows by name.

Then flip to enforcing and point applications at SCRUBR instead of the provider. One binary on a laptop; the same config in Kubernetes via Helm when you need HA and a Redis-backed vault.

What you tell the auditor

Every masked transaction lands in a hash-chained, tamper-evident log. The claim "no secret crossed the wire after date X" stops being a policy statement and becomes a verifiable property — which is the sentence your SOC 2 assessor actually wants to hear.