The Timing Gap in Cloud DLP

Data Loss Prevention tools like Nightfall, Forcepoint, and similar platforms are designed for a specific threat model: detecting sensitive data in content that is already in transit or already stored in a third-party system.

For email, documents, and Slack messages, this is appropriate. A pre-send DLP scan on every email would add too much latency. The data is going somewhere eventually; scanning it in transit is a reasonable compromise.

AI coding tools have a different timing model. When a developer sends a prompt to GitHub Copilot or Claude Code, the entire request leaves the developer's workstation in a single HTTPS call. The path is direct: the data goes from the developer's machine to Microsoft or Anthropic servers in a single hop.

By the time a cloud DLP tool sees the data, it is already on third-party infrastructure. The "prevention" step in DLP has already been skipped.

How Cloud DLP Handles AI Tool Traffic

Cloud DLP for AI coding tools typically works in one of two ways:

CASB-based interception

Cloud Access Security Brokers can be configured to intercept HTTPS traffic to known AI API endpoints, decrypt it (requiring certificate pinning bypass), scan the content, and re-encrypt. This approach requires deploying a root CA certificate on every developer workstation to enable the man-in-the-middle decryption.

The operational overhead is significant: certificate management, CA distribution, developer device enrollment. And the timing problem remains: the scan happens in transit, adding latency and complexity while the data still reaches third-party infrastructure.

Post-send log analysis

Some platforms analyze network logs after the fact, flagging calls that appear to contain sensitive patterns. This is detection, and prevention is a separate step. The data has already been transmitted before the flag is raised.

The Local-First Model

Local-first security means the enforcement point runs on the developer's workstation, before data leaves the network. For AI coding tools, this means a local proxy.

The request flow:

Developer IDE
      |
      v
Local Pretense Proxy (localhost:9339)
  - Extract code blocks from prompt
  - Swap secrets (API keys, tokens) for stand-in tokens
  - Flag emails and phone numbers
  - Mutate proprietary identifiers
      |
      v
AI API (Anthropic / OpenAI / GitHub)
  - Receives only synthetic code and stand-ins
      |
      v
Local Pretense Proxy (reverse pass)
  - Swap identifiers back, byte-exact
  - Secrets stay as stand-ins by design
      |
      v
Developer IDE
  - Receives code with real identifier names

The critical difference: the mutation happens before the HTTPS request is formed. The data that leaves the developer's machine is already protected. Interception in transit becomes moot because the payload is already synthetic.

Performance Comparison

Cloud DLP adds latency in two places: the TLS interception adds 80-150ms per request, and the content scan adds another 50-200ms depending on content size. For AI coding tools where completion latency is already 1-3 seconds, adding 200-350ms of DLP overhead is noticeable.

Local proxy mutation adds 2-8ms per request. This sits below the perceptible threshold for AI coding tool completions.

The Data Residency Argument

Cloud DLP solutions process your code on their infrastructure. You are adding a second third party to the data flow: the AI API provider and now the DLP provider.

For teams concerned about IP exposure, this works against the goal. You are trying to keep proprietary code inside your network, and the mechanism you use to do that sends the code to a third party for scanning.

Local-first security avoids this problem. The mutation runs locally. The audit log is stored locally. The mutation map stays on your machine, and Pretense's infrastructure stays out of the data path. The only data that leaves the developer's machine is synthetic code.

Deployment Differences

Enterprise cloud DLP deployments typically require:

• -2-4 week professional services engagement for initial setup
• -Certificate authority deployment and device enrollment
• -Network architecture changes for traffic interception
• -Ongoing CA certificate management
• -Vendor integration for SIEM and audit systems

Pretense local proxy deployment:

curl -fsSL https://pretense.ai/install.sh | sh
pretense init
pretense start
export ANTHROPIC_BASE_URL=http://localhost:9339

The 30-second deployment reflects the architectural simplicity of local-first enforcement.

Cost Comparison

Nightfall DLP starts at roughly $5,000 per month for enterprise plans, with pricing that scales with data volume. The professional services deployment adds $10,000-$25,000 to first-year cost.

Pretense Enterprise is $99/seat/month. For a 50-person engineering team: $4,950/month. For a 200-person team: $19,800/month, still below Nightfall's minimum.

And where Nightfall routes your code to a third-party DLP server, Pretense keeps it on your machine. The protection is genuinely local.

How I run Pretense on my own code

I build Pretense with Claude Code, and my sessions run through it. Here is the setup I give a new engineer, in order.

1. -Run the agent through the proxy. Type pretense run claude where you would type claude. It starts a local proxy on port 9339, points Claude Code at it and stops the proxy when the session ends. Detected secrets and PII leave the laptop as stand-in tokens.
2. -Put hooks on every repo. pretense install adds a pre-commit and a pre-push hook. A key that never lands in git is a key an agent never reads.
3. -Scan before an agent reads the repo. pretense scan path . lists what it finds. In CI, pretense scan ci exits 0 when clean, 2 on findings and 3 when it examined nothing. Treat 3 as a failure.
4. -Preview the swap. pretense review . shows what would be mutated. pretense mutate <file> --preview prints one file mutated and leaves the file on disk as it was.
5. -Round-trip a file you need to share. pretense mutate <file> --map <map> swaps the secrets in place. pretense reverse <file> --map <map> turns it back into the original, byte for byte, from the encrypted map on your machine. We run that round trip on real files before every CLI release and compare sha256 hashes.

One thing I learned the hard way: inside a session the agent sees stand-ins, so a file the agent writes can hold a stand-in where you expected a real value. Grep what the agent wrote before you ship it.

What Pretense will not do is put a secret back into the model's answer. Code identifiers come back byte-exact. Secrets and PII stay as stand-ins in the response. That is deliberate: a prompt-injected model can echo a token into a link, and reversing it there would hand over the real key.

What this means if you buy security

The outcome: your engineers keep their AI coding tools, and detected secrets and PII leave each laptop as stand-in tokens.

• -The control sits on the endpoint. The swap runs on the developer's machine before the request leaves. No shared gateway holds every team's keys.
• -You get evidence, not a memo. pretense audit --format csv exports every mutation event. Add --framework SOC2 to keep only the events that map to that framework.
• -Check it on your own code. Detection is pattern and entropy based, and coverage varies by data type. Run pretense review . on a real repo and read what it catches before you sign off.
• -Start with one team. One repo, pretense run claude, one week. Then read the audit log with the team lead.

Try it on your own repo: create a free account, then run npm i -g @pretense/cli and pretense run claude. If you need a security review first, talk to me.