Why SOC2 Auditors Are Asking About AI Tools Now

SOC2 Type II audits evaluate the operational effectiveness of controls over a 6-12 month period. AI coding tools became mainstream in 2023-2024. That means auditors evaluating controls through 2025 and 2026 are looking at periods when your developers were already using Copilot, Claude, and Cursor daily.

The Trust Services Criteria leave AI coding tools unnamed, and they can afford to. The relevant criteria are written broadly enough to cover any mechanism by which data leaves your control environment.

The Relevant Controls

CC6.7: Transmission of Confidential Information

CC6.7 requires that entities "restrict the transmission of confidential information using end-user messaging systems, email, or other communication mechanisms by authorized users to only authorized external parties."

AI coding tool API calls are transmissions. The code sent in prompts is potentially confidential information. The question your auditor will ask: what controls ensure that only authorized data is transmitted?

CC6.1: Logical Access Restrictions

CC6.1 requires that logical access is restricted to authorized users. When developers send code to AI APIs, that code is being processed by a third party. CC6.1 requires demonstrating that the scope of this access is controlled and documented.

CC7.2: Monitoring for Anomalies

CC7.2 requires monitoring for anomalies and events that could indicate security threats. Bulk code transmission to AI APIs, particularly from accounts that rarely make API calls, is exactly the type of anomaly this control addresses.

What Auditors Will Ask For

Based on audit preparation conversations with security teams in 2025-2026, auditors are asking for:

1. -A written policy governing AI tool usage that includes data classification restrictions
2. -Technical evidence that the policy is enforced (beyond being communicated)
3. -Audit logs showing what was transmitted and when
4. -Evidence of incident review process when policy violations occur

A policy document alone satisfies zero of these. You need the technical controls and the logs.

Building the Control Stack

Step 1: Write the Policy

Your AI tool usage policy needs to cover:

• -Approved tools (name them specifically; an allowlist is more auditable than a blocklist)
• -Data classification rules (define which data categories may be included in AI prompts and which must stay out)
• -Enforcement mechanisms (how the policy is enforced, beyond how it is communicated)
• -Exception handling (how developers request approval for edge cases)
• -Incident reporting (what to do when sensitive data is accidentally sent)

Template control statement you can adapt:

"[Company] permits the use of approved AI coding tools for software development activities. Developers include source code containing [data classification categories] in AI tool prompts only with prior approval. All AI API traffic from developer workstations is routed through the approved Pretense proxy, which enforces data mutation controls and generates audit logs for compliance review. Audit logs are retained for [retention period] and reviewed [quarterly/on incident trigger]."

Step 2: Implement the Technical Control

The most auditor-friendly technical control is a proxy that sits between developer workstations and AI APIs. This approach provides:

• -A single enforcement point (easier to audit than per-developer configurations)
• -Complete audit logs (every API call is logged with timestamp, content hash, mutation record)
• -Demonstrable enforcement (you can show the auditor traffic flows)

Pretense deploys as a local proxy on each developer workstation or as a network-level proxy for the engineering subnet:

# Per-developer deployment
curl -fsSL https://pretense.ai/install.sh | sh
pretense init
pretense start --port 9339

# Environment variable routes all AI API traffic through proxy
export ANTHROPIC_BASE_URL=http://localhost:9339
export OPENAI_BASE_URL=http://localhost:9339

For the network-level approach, Pretense can be deployed as a Docker container that handles routing for the entire engineering network. See the deployment documentation for the Docker Compose configuration.

Step 3: Generate the Audit Artifacts

Pretense generates SOC2-ready audit logs in JSON format:

{
  "timestamp": "2026-04-03T14:23:11Z",
  "developer": "engineer@company.com",
  "repository": "payment-service",
  "file": "src/payments/processor.ts",
  "identifiers_scanned": 47,
  "identifiers_mutated": 12,
  "secrets_detected": 0,
  "model": "claude-3-5-sonnet",
  "tokens_sent": 1842,
  "mutation_map_id": "mm_7x2k9p"
}

Each log entry includes what was scanned, what was mutated, whether any secrets were detected (and swapped for stand-ins that stay in the answer), and the full mutation record for verifying that identifiers were swapped back byte-exact.

Pretense exports the audit log filtered to SOC 2:

pretense audit --format csv --framework SOC2 --limit 100000 > q1-2026-ai-security.csv

The export lists each mutation and tokenization event that maps to SOC 2. Filter it to the quarter you are sampling.

The Four Artifacts Your Auditor Wants

When your auditor asks about AI tool controls, prepare these four artifacts:

With these four items, you can answer every AI tool question in a SOC2 review.

Audit Findings to Get Ahead Of

Finding: Missing documented AI tool policy

The fix is straightforward: write the policy, get it approved, distribute it. The harder part is making it enforceable, beyond advisory.

Finding: Policy communicated, technical enforcement missing

This is the finding that a proxy control addresses directly. "We sent an email" falls short as a control. A proxy that enforces mutation and generates audit logs qualifies.

Finding: Audit logs omit request content

Generic network logs capture connection metadata and leave out request bodies. Your auditor has to see more than a TCP log to verify what was sent. The proxy log must include content evidence (even hashed) to be useful.

Finding: Retention period left undefined

Define a specific retention period in your policy and configure the audit log accordingly. 12 months is standard for SOC2.

Getting to Audit-Ready

Timeline for a team starting from zero:

• -Week 1: Write and approve the AI tool policy
• -Week 2: Deploy Pretense proxy across the engineering team
• -Week 3-4: Validate audit log completeness and format
• -Ongoing: Monthly review of mutation statistics and any detected anomalies

The SOC2 conversation becomes straightforward when you have 90 days of clean audit logs and a policy that matches what the technical control actually enforces.

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.