Is Claude Code Safe for Company Code? Where Bans, DLP, and ZDR Stop Working

Is Claude Code safe for company code? If you own your company’s AI coding-assistant policy, here’s the direct answer: the question decomposes by layer. The provider layer (enterprise terms plus a zero-data-retention agreement) governs what happens to your data after it arrives. The machine layer (sandboxing, permissioning) governs what the agent can read and execute locally. The prompt layer governs what enters the request at all -- the moment a plaintext credential, connection string, or customer record lands in a prompt on a developer’s machine, inside a sanctioned TLS stream. Every control in the standard playbook -- bans, network DLP, cloud AI gateways, post-send secret scanners, ZDR contracts -- operates at a different layer than that last one, which is where exposure actually happens.

This isn’t an argument for tearing the playbook up; each control does a real job at its own layer. But map the five against the path a secret takes into a model’s context window, and each lands before the prompt exists (bans), beside it (DLP, gateways), or after send (scanners, retention contracts). Below: the map, each layer’s documented failure, and a requirements list for the missing one -- written so you can test any vendor against it, including Sordino.

The five controls, mapped

Can you just ban AI coding tools?

You can write the ban; most organizations have. IANS Research reported in February 2026:

Per the same polling, 56% block most tools and manage exceptions through allowlists. Restriction reaches the top of the stack: Meta reportedly limited internal Claude Code and OpenAI Codex use in June 2026 over distillation risk and proprietary-code exposure, as reported by The Information.

Enforcement is where it goes sideways. Verizon’s 2026 Data Breach Investigations Report reportedly found shadow-AI detections up 4x year over year, and PagerDuty’s 2026 Shadow AI survey (Wakefield Research, 1,250 office professionals at $500M+ companies) found 66% had used AI tools they believed violated policy. A ban doesn’t remove the exposure; it removes your visibility into it. A sanctioned enterprise account at least gives you ZDR terms, an audit trail, and an offboarding story; a personal account used around the ban gives you none of those. The trade can still be right in narrow scopes -- regulated codebases, active-litigation environments -- where you’ve priced in the leakage rate.

Why doesn’t network DLP catch secrets in AI prompts?

Traditional DLP is built around recognizable acts of exfiltration: a file attached to an email, a bulk upload, a known pattern crossing a boundary in a parseable format. Coding-agent traffic is none of that: a TLS stream to a sanctioned endpoint, carrying JSON whose payload is a conversation -- the developer’s prompt plus everything the agent pulled into context on its own (file contents, shell output, stack traces, diffs).

Two properties break inspection. First, the sensitive value sits in free-form text with no file type or schema to anchor on -- a connection string in a pasted stack trace is just characters in a string field. Second, the developer often never pasted anything at all: coding agents read .env files and run shell commands as part of normal operation, and that output enters the request without a human in the loop.

Enforcement options don’t rescue it. Block mid-stream and you sever an agent session mid-edit, training developers to route around the control. Alert-only is detection after send. Terminate TLS to inspect and you’ve signed up to reassemble streamed conversational JSON at line rate and pattern-match it live -- the scanners’ detection problem from a worse vantage point -- while concentrating your most sensitive prompt plaintext at one inspection point.

Does a cloud AI gateway close the gap?

A hosted gateway that redacts prompts before forwarding them does redact -- in its own cloud, which means it processes your plaintext to do it. Whatever trust question you asked of the model provider now applies to a second vendor: retention, logging defaults, breach surface, subpoena exposure. If the pitch is “we redact before the model provider sees it,” the operative question is what the redactor saw. Cloud-side redaction relocates the exposure rather than removing it; if your requirement is “plaintext secrets never leave our machines,” a gateway can’t meet it by construction. Gateways earn their keep on other axes -- routing, budgets, rate limits -- so keep one for those reasons. Just don’t book it as the confidentiality control.

Can a secret scanner prevent secrets in prompts?

Scanners are the most defensible item on the list, and I’d deploy one regardless. GitGuardian’s ggshield added AI hooks in April 2026 scanning at prompt-submit, pre-tool, and post-tool stages in Cursor, Claude Code, and VS Code. The first two run before the sensitive action. The third, per the showcase:

That’s the honest boundary of any post-hoc stage: notification starts your rotation clock -- real value, not control. The deeper problem is adversarial: Microsoft Threat Intelligence documented a prompt-injected Claude Code instance in a GitHub Action instructed to strip the sk-ant- prefix from a credential so the exfiltrated output would evade signature-based scanners -- once a model has seen a secret, output-side scanning is a race you can lose by instruction. The full trace of one pasted secret’s travels, and the first-hour checklist if a scanner does fire, is in the life of a pasted secret.

Doesn’t a zero-data-retention contract cover this?

A ZDR agreement is worth negotiating -- and it governs one layer: the provider’s handling of your data after it arrives. Even under ZDR, Anthropic retains user-safety classifier results and can keep flagged sessions -- the Claude Code ZDR docs scope the promise “except where needed to comply with law or combat misuse.” Effective June 9, 2026, Mythos-class models carry a mandatory ~30-day safety retention, including for ZDR organizations, which must explicitly enable retention to use them. On May 13, 2025, a preservation order in the New York Times case forced OpenAI to keep ChatGPT logs it would otherwise have deleted; ZDR API customers and ChatGPT Enterprise were explicitly carved out. The carve-out is the argument for having the contract; the order is proof the protection is a legal artifact with a scope and a date, not a property of your data. The full envelope is in what ZDR actually covers.

What does a prompt-layer control actually need to do?

If a product claims to close the prompt gap, test it against these four vendor-neutral requirements -- including Sordino.

1. Process locally. Masking has to run on the developer’s machine, before the bytes leave it. Plaintext that transits someone else’s infrastructure to get redacted is the gateway problem again.

2. Substitute reversibly and deterministically. Blocking sends developers back to shadow AI; one-way redaction breaks the workflow -- the model’s answer comes back referencing [REDACTED] and can’t be used. Substitution needs to be deterministic (the same value always maps to the same token, keeping multi-turn sessions coherent and prompt caching stable) and locally reversible (tokens in responses swap back before the developer sees them). A control that degrades the tool gets routed around; adoption is a security property.

3. Cover tool output, not just typed prompts. In agentic workflows the dominant path for a secret into a prompt isn’t a paste; it’s the agent reading a config file or running a command whose output contains an env var. Both context directions -- user input and tool output -- need masking before send.

4. Produce audit evidence. Per-session evidence of what was sent and what was masked -- for client questionnaires, compliance reviews, incident response. Visibility runs the other way too: enterprise AI plans give org admins audit and export access (Anthropic’s ZDR docs list audit logs among admin capabilities), so treat work AI accounts like work email. With masking upstream, an admin export -- or a retention carve-out -- holds tokens, not values.

One implementation note: per-project isolation (separate keys, salts, and token stores per codebase) keeps a compromised store’s blast radius at one project.

How Sordino implements the prompt layer

Sordino is a local masking proxy built against that list. It installs as a Claude Code plugin and runs loopback-only -- no TLS interception, no certificates, since Claude Code natively honors ANTHROPIC_BASE_URL. Detected sensitive spans on the masked wire surfaces (typed prompt and tool output both) reach the provider only in tokenized form, enforced fail-closed at the proxy: if masking fails, the request is refused, not forwarded unmasked. That’s the mechanical line between prevention and the notify-after-send stage above; values you explicitly register as secrets are masked unconditionally. Tokens are deterministic and reversed locally on the way back; the token-to-value table stays local, encrypted with AES-256-GCM. The full mechanism is in the docs.

Sordino Enterprise adds the organizational layer: custom masking rules beyond credentials (customer data, internal identifiers, even code patterns), live visibility into what was sent versus what was masked -- the evidence artifact client questionnaires ask for -- plus guided or fully managed setup. The project’s framing is blunt: “Not zero data retention — zero data access. The AI never had your secrets to begin with.” Details: /enterprise.

What this doesn’t solve

Hold Sordino to the same standard; two limits matter most.

Detection recall is not 100%, and free-text PII is the hard case. Out-of-the-box detection is pattern-based, plus an optional local ML model; a value matching no recognizer and no custom rule goes through. The research is blunt about the ceiling: PIIBench (2026) found all eight PII-detection systems it tested collapsed out-of-distribution -- under 0.14 F1 on unfamiliar domains, versus 0.9+ in-distribution. That’s the honest scope for every vendor here, Sordino included: structured secrets (keys with known prefixes, recognizable entropy, connection strings) are the tractable core; free-text PII across arbitrary domains is unsolved. Enterprise custom rules and registered secrets narrow the residual; nothing eliminates it. Assume recall below 100% and keep rotation, least-privilege, and .gitignore hygiene in place -- masking catches what slips past them, it doesn’t replace them.

The local-agent tier is a different problem. Masking governs egress to the provider on the LLM wire. An agent with shell access can still read local files, and masking doesn’t sit on non-LLM egress either -- a curl in a tool call, a git push, an MCP server’s own network calls. That’s a sandboxing and permissioning problem, a separate policy tier no masking product substitutes for. Budget for both layers.

How do we prevent secrets in prompts without breaking developer workflow?

Mask at egress: locally, reversibly, deterministically, across typed prompts and tool output both. Reversibility is the workflow-preserving property -- the developer and the tool keep seeing real values locally while the provider sees tokens. A control that breaks the tool’s round-trip gets disabled by the people it governs.

Does prompt-layer masking replace DLP or ZDR?

No -- layers stack. Keep ZDR; the NYT carve-out is the demonstration that it matters. Keep post-hoc detection; a notification that starts the rotation clock beats silence. Masking occupies the one layer the rest of the playbook doesn’t: a detected value leaves the machine as a token, so what’s downstream to retain, leak, or subpoena is the token, not the secret.

Do the same control layers apply to Cursor and GitHub Copilot?

Yes -- the decomposition is about the workflow, not the vendor. Every agentic coding tool assembles prompts from typed text, file contents, and shell output on a developer’s machine and ships them over sanctioned TLS, so the same five controls miss the same layer for all of them. Sordino covers Claude Code and OpenAI Codex today -- not Cursor or Copilot -- but the requirements list is vendor-neutral: apply it to whatever tool and control you’re evaluating.

So is Claude Code safe for company code?

Safe the way anything in security is safe: per layer, with named residual risks.

• Provider layer: enterprise terms plus ZDR -- real, worth negotiating, enabled per-organization by the account team on qualifying accounts, scoped as above. On training, Anthropic’s Commercial Terms (June 17, 2025) state that “Anthropic may not train models on Customer Content from Services”; consumer plans don’t train by default but carry an opt-in toggle and safety carve-outs, so verify your tier and your toggle (the per-tier breakdown has sources). If a BAA is in play, ask whether it covers the coding tool, not just the chat product.
• Machine layer: sandboxing and permissioning over what the agent can read and execute -- see the limits above.
• Prompt layer: a control that keeps plaintext secrets out of the request in the first place -- the four requirements above.

A policy that answers all three can defensibly say yes. A policy that only has the first is carrying the gap this article maps -- and it’s a gap the size of every prompt your developers will send today.

If you’d rather evaluate before talking to anyone: the core is open source and free for individuals. Install it on one project and read what it sends.