Skip to main content
By default, a value like [email protected] leaves your machine as {{REDACTED_EMAIL}}. With the Privacy Shield off, it leaves as [email protected]. That is the whole of what bypass does: it stops the on-device redaction step, so snapshots reach the cloud unredacted. Everything else — compression, sessions, billing — is unchanged. 
Default (Shield on):                 Bypass (Shield off):
  Email:  [email protected]            Email:  [email protected]
   ↓ leaves machine as                  ↓ leaves machine as
  {{REDACTED_EMAIL}}                    [email protected]
This page is the full walkthrough. For where bypass sits in the overall posture, start with Privacy posture.

​
Who this is for

Bypass exists for a narrow case. It’s the right choice when all of these are true:
  • You run your own model endpoint, or otherwise control the data boundary the snapshots flow into.
  • You value JD Codec for compression, not redaction.
  • You have consent for the data you’re processing, or the real values are the point — for example an internal benchmark or a dataset you’re building.
If you’re not sure bypass is right for you, it isn’t. The default — Shield on — is the right setting for almost everyone.

​
What you’re accepting

Stated plainly, with bypass on:
  • Unredacted page content and URLs reach the cloud, and from there your downstream LLM.
  • The Shield does not run. It’s all-or-nothing, not per-field — you can’t bypass for some values and redact others.
What does not change, and still holds under bypass:
  • We never persist your snapshot bodies. Snapshot YAML lives only in transient session state and is cleared on TTL or restart — same as the default path. See what’s persisted.
  • URLs are minimized in our records. Because the URL is no longer guaranteed clean under bypass, we keep only its structure in usage records and logs — host, path, and query parameter names — and drop every query value, fragment, and userinfo. This is a best-effort minimization, not a guarantee: a path segment can still carry a value. The authoritative record that a send was unredacted is the bypass flag itself.
  • Every bypassed request is audit-tagged on our side, and your bypass usage is visible to you on request.
  • The default stays fully shielded for every other key. Bypass is per key.

​
How to turn it on

Two independent things must both be true. Either one alone does nothing. Step 1 — ask us to provision your key. Bypass is enabled per key, on our side. There is no self-service toggle. Contact support to enable it for your key. Step 2 — opt in from your connector. Set both of these: 
JDC_PRIVACY_SHIELD=off
JDC_PRIVACY_SHIELD_BYPASS_ACK=1
Or, in ~/.jdcodec/config.json: 
{
  "privacy_shield": "off",
  "privacy_shield_bypass_ack": true
}
The off-switch alone won’t do it. If you set JDC_PRIVACY_SHIELD=off without the acknowledgement, the connector keeps the Shield on and logs a one-time warning telling you the acknowledgement is also required. This two-step is deliberate — an unredacted send should take two conscious actions, not one. You’ll also see a warning line in your connector logs on every snapshot while bypass is active. That’s intentional, not an error.
If your key is not provisioned for bypass, turning it on connector-side has no effect on what’s accepted: the cloud returns 400 privacy_shield_missing for an unredacted send from a key that isn’t permitted. The connector cannot open the gate on its own.

​
How to turn it back off

Either side is enough:
  • Connector side — remove the two settings (or set JDC_PRIVACY_SHIELD back to on). The Shield runs again on the next snapshot.
  • Our side — ask support to revoke the key’s bypass permission. This takes effect within about 30 seconds.

​
What this does not change

  • The default for every other key stays fully shielded.
  • Compression, sessions, and billing units are unchanged.
  • Nothing about what we persist changes — we still never store snapshot bodies.