The Audit Question Every Team Should Prepare For

In 2025, SOC 2 auditors began systematically asking about AI coding tool usage across all Type II engagements. The question usually surfaces in the Change Management or Logical Access controls:

"Do engineers use AI coding assistants? What data is transmitted to AI providers? What controls are in place?"

Most security teams scramble. Their answers are thin because the tooling evolved faster than the compliance frameworks.

The SOC 2 Trust Services Criteria That Apply

AI coding tool usage touches multiple TSC domains:

CC6.1: Logical Access Security: AI tools require API keys. Are those keys managed with the same rigor as other access credentials?

CC6.6: Transmission Security: Code transmitted to AI providers is data in transit. What encryption is in place? Do the providers hold their own SOC 2 reports?

CC7.2: System Anomalies: Unusual spikes in AI API usage could indicate misuse. Is this traffic monitored?

PI1.2: Privacy and Data Classification: Is there a process that keeps classified data with your developers and away from AI providers?

What Auditors Are Looking For

Based on SOC 2 audit conversations in 2025 to 2026, auditors now expect four things:

1. A data classification policy that covers AI tools: explicitly stating which data categories must stay internal and which providers are approved.

2. Technical controls that enforce the policy: a policy document that lacks technical enforcement gets a finding. Auditors want to see that the system itself stops classified data from going out by accident.

3. Evidence of monitoring: audit logs showing what was sent, by whom, and when. Evidence that those logs are reviewed.

4. Vendor assessment for AI providers: SOC 2 compliance from OpenAI and Anthropic covers their own systems. Your obligation is to assess whether terms of service, data retention, and security practices meet your requirements.

The Control Framework

Policy Layer

# AI Coding Tool Policy

Approved Tools: GitHub Copilot Business, Claude Code via Pretense proxy, Cursor with Pretense proxy

Data Classification Rules:
Public: Yes, unrestricted
Internal: Yes, with mutation proxy active
Confidential: No, must use local model only
Restricted: Swapped for stand-ins by proxy
Secrets: Swapped for stand-ins by proxy

Technical Control Layer

# pretense.config.yaml
proxy:
  port: 9339
  approved_providers:
    - api.openai.com
    - api.anthropic.com
secret_scan:
  enabled: true
  block_on_critical: true
mutation:
  enabled: true
audit:
  enabled: true
  retention_days: 365
  siem_export: true

Evidence Layer

The audit log provides the evidence auditors need:

{
  "timestamp": "2026-03-01T09:14:33Z",
  "event": "prompt_transmitted",
  "developer": "engineer@company.com",
  "provider": "anthropic",
  "prompt_token_count": 847,
  "secrets_swapped": 0,
  "mutations_applied": 12,
  "classification_level": "internal"
}

The Three Common Gaps

Gap 1: Missing logs: You have a policy and approved tools, yet zero logs showing the policy is enforced. "We trust our developers" falls short as a control answer.

Gap 2: Policy that lacks enforcement: The policy says keep PII out of AI tools, yet a technical control to enforce it is absent. Auditors treat this as an ineffective control.

Gap 3: Vendor management gaps: OpenAI holds a SOC 2 Type II report. Have you reviewed it? Do you have a record of that review? Vendor management requires documentation.

The Evidence Package

For a clean SOC 2 audit related to AI coding tools, prepare:

1. -AI tool policy (current version, version history)
2. -Approved provider list with justification for each
3. -Vendor SOC 2 reports from OpenAI, Anthropic (download from their trust portals)
4. -Technical control documentation (proxy configuration, scanning rules)
5. -Audit log samples (3 to 6 months)
6. -Incident log (any policy violations and how they were handled)
7. -Training records (evidence developers were trained on the policy)

Timeline to Compliance

The technical deployment takes 1 to 2 days. The policy and evidence collection takes 2 to 3 months to build up sufficient evidence for an audit period. Start now, well ahead of the week before your audit.

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.