> ## Documentation Index
> Fetch the complete documentation index at: https://jdcodec.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Turning the Privacy Shield off (bypass)

> When and how to send un-redacted snapshots — and what you're accepting.

By default, a value like `alice@example.com` leaves your machine as `{{REDACTED_EMAIL}}`. With the Privacy Shield off, it leaves as `alice@example.com`.

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:  alice@example.com            Email:  alice@example.com
   ↓ leaves machine as                  ↓ leaves machine as
  {{REDACTED_EMAIL}}                    alice@example.com
```

This page is the full walkthrough. For where bypass sits in the overall posture, start with [Privacy posture](/docs/concepts/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](/docs/concepts/privacy-posture#whats-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](mailto:hello@jdcodec.com?subject=Privacy%20Shield%20bypass) to enable it for your key.

**Step 2 — opt in from your connector.** Set both of these:

```bash theme={null}
JDC_PRIVACY_SHIELD=off
JDC_PRIVACY_SHIELD_BYPASS_ACK=1
```

Or, in `~/.jdcodec/config.json`:

```json theme={null}
{
  "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.

<Note>
  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.
</Note>

## 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.