Why AI Coding Tools Need Their Own Section in Your DLP Policy

Most enterprise data loss prevention policies were written before AI coding assistants existed. They cover email attachments, USB drives, and cloud storage. They leave out the case where a developer types "refactor this function" into Claude Code and sends 300 lines of proprietary TypeScript as context.

This gap is real. It is happening in your organization today. The average enterprise engineering team has 60 to 80 percent adoption of AI coding tools within 18 months of the tools becoming available. Until you write a policy, your developers are making their own decisions about what is acceptable to send.

This guide gives you a working policy framework you can adopt and adapt.

The Four Questions Your Policy Must Answer

Before writing a single line of policy, answer these four questions for your organization:

1. Which AI coding tools are approved? Enumeration matters more than principles. Developers need a list: Claude Code is approved, Copilot is approved, the random AI tool a developer found on GitHub is off the list. Unapproved tools route to personal accounts that lack contractual protections. Your policy needs to list exactly which tools are on the approved list and what approval requires.

2. What data classifications are permitted in AI prompts? A three-tier framework works for most organizations. Public information can go anywhere. Internal information can go to approved tools with a standard BAA or data processing agreement. Confidential and restricted information (which includes proprietary algorithms, credentials, and PII) requires a technical control on top of a policy statement.

3. How do you verify compliance? Policies become controls once they have enforcement. Your policy needs a mechanism: a proxy that logs all LLM API traffic, CI/CD gates that block unapproved endpoints, or required tooling like Pretense that enforces mutation before transit. A policy that says "developers should keep proprietary code out of prompts" and lacks a mechanism to verify compliance falls short of a control.

4. What is the exception process? Developers will find legitimate reasons to need exceptions. A clear exception process (security review, manager approval, time-limited) keeps exceptions visible and documented. A defined process keeps developers inside the policy; its absence pushes them around it.

Policy Template: AI Coding Tool Usage

The following is a template you can adapt. Replace bracketed text with your organization's specifics.

Scope: This policy applies to all engineering employees and contractors who use AI-assisted coding tools in connection with [COMPANY NAME] systems, codebases, and data.

Approved Tools: The following AI coding tools are approved for use: [LIST APPROVED TOOLS]. All other AI coding tools require written approval from the Security team before use.

Data Classification Requirements:

• -Public data: May be included in AI prompts freely.
• -Internal data: May be included in prompts to approved tools subject to existing data processing agreements.
• -Confidential data (proprietary algorithms, system architecture, business logic): Must be protected using an approved technical control before inclusion in any AI prompt. Currently approved controls: Pretense mutation proxy.
• -Restricted data (credentials, PII, PHI, payment card data): Must stay out of AI prompts. Secrets scanners in the CI/CD pipeline enforce this automatically.

Enforcement Mechanism: All AI API calls from company development environments must route through the Pretense proxy at localhost:9339. The proxy enforces mutation of confidential identifiers and swaps detected secrets for stand-in tokens, while flagging emails and phone numbers by default. CI/CD pipelines include a gate that verifies API calls are routed through the proxy.

Audit Requirements: Every AI coding session that includes company code must produce an audit log entry. The Pretense audit log meets this requirement automatically. Audit logs are retained for [RETENTION PERIOD, e.g., 13 months] and are available to the Security team on request.

Incident Reporting: Any suspected transmission of restricted data to an AI tool must be reported to the Security team within 24 hours using the standard incident reporting process.

Exception Process: Exceptions to this policy require written approval from the CISO or their designee, documentation of the business justification, a 90-day review date, and enhanced monitoring for the duration of the exception.

The Tool Approval Process

Many CISOs make tool approval the bottleneck. Make it a checklist:

The tool requires a data processing agreement or BAA before your legal team will approve it. For most major AI providers (Anthropic, OpenAI, Microsoft), these agreements exist and can be signed in under a week. For smaller or newer providers, a missing DPA is itself disqualifying.

The tool's API traffic can be routed through a local proxy. Tools that require direct cloud connectivity and resist proxying present a verification problem. You can audit only what you can intercept.

The tool stores prompt data for model training by default. Verify the opt-out from training data use explicitly, and treat it as unconfirmed until verified. Major providers offer this on enterprise tiers. Verify it contractually, beyond a privacy policy.

The tool has a SOC2 Type II report available. This is a minimum bar for enterprise software. If the vendor is unable to produce a report, keep the tool away from confidential data.

Pretense as the Implementation Layer

Writing a policy is step one. The harder problem is enforcement at scale. When you have 200 engineers making hundreds of AI calls per day, relying on each engineer to classify data correctly and make the right decision is a gamble.

Pretense takes the decision off the developer's plate. Once configured, the proxy automatically:

• -Scans every prompt for secrets (API keys, credentials, tokens) and swaps them for deterministic stand-ins, flagging emails and phone numbers by default
• -Mutates proprietary identifiers before transmission, so what leaves the network is always stand-ins in place of the real code
• -Logs every session with mutation count, secrets mutated, model used, and timestamp
• -Swaps identifiers back byte-exact in responses so developers receive working code with real names, while secrets stay as stand-ins by design

The policy says confidential data requires a technical control. Pretense is that control. It is deployed in 30 seconds and runs transparently in the developer's existing workflow.

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

That four-command sequence brings a developer into policy compliance. For team-wide enforcement, set the environment variable in the shared development environment and add the CI gate that verifies proxy routing.

Audit Evidence Your Compliance Team Needs

For SOC2, ISO 27001, and HIPAA, auditors will ask three questions about AI tool usage:

What controls exist to prevent unauthorized data transmission? Answer: Pretense mutation proxy with secret swapping.

How do you know the controls are working? Answer: Audit log with per-session mutation counts, secret-swap events, and model endpoint records.

How long are audit records retained? Answer: [Your retention period]. Export with pretense audit --format csv --limit 100000.

The audit log is the artifact. It turns an assertion of control into evidence. With it, you can walk an auditor through exactly which sessions occurred, what was protected, and what was swapped.

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 own compliance

The outcome: a technical control for AI coding tools that you can show an auditor. Pretense helps with SOC 2, HIPAA, PCI DSS and GDPR evidence. It maps to controls. It does not certify you.

• -Pin the preset you report against. pretense scan path . --policy soc2 applies that framework's detectors. SOC 2 and PCI presets come with Startup. HIPAA, GDPR and NIST presets come with Enterprise.
• -Export the evidence. pretense audit --format csv --framework HIPAA writes the events that map to HIPAA. Attach the file to the control with the date range you sampled.
• -Test detection on your own data. Coverage varies by data type. Run pretense review . on a regulated repo, read the result and record the gaps in your risk assessment.
• -Keep the policy and the control in step. Your AI tool policy says what engineers may send. pretense run claude and the git hooks are how you show it happens.

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.