SOC 2 and AI coding agentsWhich controls apply. What auditors will ask.

Your SOC 2 Type II auditor doesn't have an "AI coding agents" line item. They have trust-services criteria written in 2017, updated in 2022, and applied to what your engineering team is actually doing in 2026: Claude Code sessions with prod credentials in the shell, MCP servers making outbound API calls from developer laptops, and commits where the author is human but the code is not.

The criteria don't care about the author. They care about access, transmission, detection, and change management. AI coding agents touch all four.

This isn't a warning about future risk. Knostic's February 2026 disclosure found Claude Code writing environment variables, including production secrets, into per-project state files that shipped in npm packages. GitGuardian's 2026 State of Secrets Sprawl report shows AI-assisted commits leak at roughly twice the baseline rate. These are findings, not hypotheticals. If your developers use coding agents against production-adjacent environments, your current SOC 2 evidence package almost certainly has gaps.

The five criteria below are where auditors will look.

What to know in 60 seconds

• CC6.1 covers logical access controls. An agent reading your shell environment is logical access. If you can't document who granted that access or what it covered, you have a CC6.1 gap.
• CC6.7 covers data transmission outside your trust boundary. What goes to the model API, including context, file contents, and conversation history, left your perimeter.
• CC8.1 covers change management. Agent-generated code that goes to production needs the same review trail as any other code change.
• Auditors in 2026 are asking specifically about agent inventories and state files. "We don't use agents" is not a credible answer.
• The evidence you need to collect is tractable: grant logs, MCP allowlists, CI redaction reports, review records. None of it requires new tooling if you're already logging.

Which TSC criteria actually apply

CC6.1: logical access controls

CC6.1 requires that you document and control access to systems, including who can access what and on what basis. When a developer launches a Claude Code session with STRIPE_SECRET_KEY and DATABASE_URL in their shell environment, the agent can read both. That is logical access to production credentials.

Most access-control programs document users and service accounts. They don't document agent sessions. The question from the auditor is: what access controls govern whether a developer can run an agent session with production credentials in scope? If the answer is "nothing formal," that's a finding.

The minimum evidence: a policy that defines allowed environments for agent sessions (for example, agents may not run with production credential scope outside a designated staging environment), and a log showing the policy is enforced.

CC6.6: network protections

CC6.6 requires network-level controls that restrict access to authorized parties. MCP servers installed on developer laptops make outbound calls, and the scope of those calls depends on which MCP servers are installed and what they can reach.

OX Security's early 2026 analysis found roughly 7,000 MCP servers in active use, with approximately 150 million downloads, and no package-level signature requirement. A developer can install an MCP server that makes outbound calls to any host. If that server runs in the context of an agent session with production credentials in scope, you have an outbound data path that your network controls don't cover.

The minimum evidence: an inventory of MCP servers on developer workstations (name, version, hash), a defined allowlist of permitted servers, and documentation of how you enforce the allowlist.

CC6.7: data transmission outside the trust boundary

CC6.7 covers transmitting data to external parties, including encryption, classification, and consent controls. When an agent session reads a file, that file's contents are candidates for inclusion in the model API call. Context windows are large. Developers routinely open files during an agent session without tracking which ones ended up in a prompt.

What the model API receives is data leaving your trust boundary. The API transport is encrypted, so the "how" is covered. The "what" is not. If the agent session has access to a file containing a customer record, a PII field, or a production secret, and the agent reads that file, the data crossed the boundary.

This doesn't mean AI tools are prohibited. It means the classification controls you apply to email and file sharing also apply to what lands in an agent's context window.

The minimum evidence: a data-handling policy that covers model API calls, documentation of what categories of data are permitted in agent sessions, and log evidence that sessions with elevated data access are scoped or reviewed.

CC7.1: anomalous activity detection

CC7.1 requires controls to detect anomalous or unauthorized activity. Automated tool calls at 3am look exactly like a compromised credential working through a target environment, because the traffic profile is identical.

If a developer runs a long agent session overnight and the agent makes 300 API calls to your internal GitHub API between 2am and 5am, your SIEM should flag that. If it doesn't, you have a detection gap. More practically, if the SIEM does flag it and there's no process to review agent-generated anomalies separately from human-generated ones, you have a response gap.

The minimum evidence: detection rules that account for known-good agent session patterns (ideally via a session identifier or agent-specific header), a log of anomalous-activity alerts reviewed in the audit period, and documentation that reviews distinguished agent sessions from compromise events.

CC8.1: change management

CC8.1 requires that changes to systems go through a defined review, approval, and documentation process. Agent-generated code that reaches production is a change. The commit author is human. The code is not.

Most teams think CC8.1 is covered because the developer reviewed and approved the PR. The real question is whether that review is substantively different from a review where the developer wrote the code. A developer who runs an agent session producing 400 lines of authentication logic, reviews the diff, and self-approves has a weak single-party trail. The audit record should show what the agent accessed during the session, which tools it called, and whether someone other than the session developer reviewed the result.

Peer-review requirements apply to agent-generated code with the same force as any other change. The reviewer sees only the diff, not the full session transcript. That limited context is a reason to require a second set of eyes, not a reason to waive it.

The minimum evidence: commit records showing agent-generated code was reviewed and approved, preferably by someone who did not run the agent session, and documentation that the review process covers agent-generated changes explicitly.

Questions auditors will ask in 2026

These questions are showing up in 2026 audit interviews at shops running agent-assisted development. Prepare answers before fieldwork starts, not during it.

"Who can see production credentials in the agent's runtime context?" If the answer is any developer with a local Claude Code install, document the policy that governs that access or demonstrate the technical control that prevents it.

"Show me the audit trail for agent-initiated changes." A standard git log shows the committing human. Auditors want the session log showing what the agent actually did: which tools it called, which files it read, what external calls it made. If that log doesn't exist, the change management trail is incomplete.

"What's the inventory of MCP servers on developer workstations?" The auditor wants an actual list with versions, not a general description of your approval process. "Developers install what they need" is a gap answer.

"How do you prove the agent's state files don't end up in production artifacts?" This follows directly from the Knostic February 2026 disclosure. The auditor is asking whether your .gitignore, .npmignore, and .dockerignore files cover agent state paths, and whether your CI pipeline validates that claim before publishing.

"What is your classification policy for data entered into model API calls?" If the answer is "we haven't written one," that's the finding. The policy doesn't have to be restrictive. It has to exist and be applied.

Evidence to collect now

The evidence package below covers the five criteria above. None of it requires new tooling if you're already logging CI runs and code reviews.

Agent grant logs (CC6.1): every developer session running an agent against a sensitive environment should produce a log entry: who ran the agent, when, what credential scope was in the environment. A local credential manager's grant log is this artifact. If developers use ambient shell variables, you need a wrapper script or a signed policy acknowledgment for each session.

MCP server inventory (CC6.6): scan developer machines, or require self-reporting in MDM. Capture name, installed version, and SHA-256 of each binary. Document the approved allowlist. Repeat quarterly. The hash matters because a renamed binary sidesteps name-based controls.

Gitleaks CI reports (CC6.7): GitGuardian's 2026 State of Secrets Sprawl and the Knostic disclosures both trace to secrets in committed files. Run Gitleaks or an equivalent in CI, produce a signed artifact per repo per quarter, and save the reports. A clean scan is direct evidence of CC6.7 activity.

Prepublish gate logs (CC6.7): for any repo publishing to a registry, a CI step checking for agent state files before the publish step produces a per-run artifact. Save the run logs. Auditors want to see the gate ran, not just that it exists in a config file.

Code-review records for agent PRs (CC8.1): label PRs that contain agent-generated code, or add a field to your PR template. A filtered list showing each labeled PR was reviewed and approved by someone other than the session developer is your CC8.1 evidence for agent changes.

SIEM anomaly review log (CC7.1): for each quarter, a record showing that agent-session anomalies flagged by the SIEM were reviewed and closed. Even if every flag was a false positive, the review log shows CC7.1 is operating.

What most teams get wrong about this

The conventional advice: treat agent sessions like privileged access, require MFA for the developer, log session start and end, done. That satisfies a surface reading of CC6.1. It doesn't answer the follow-up questions.

A session log records one authenticated access event. The agent behind that session may have made 50 outbound MCP server calls, read a dozen production-adjacent files, and committed 600 lines of code. The auditor sees 50 network events, 12 data accesses, and a significant code change with no attribution chain between them.

A second miss is assuming the developer's code review checks the CC8.1 box. When the developer who ran the agent session is also the sole reviewer, that's single-party sign-off. For security-sensitive paths, require a second reviewer and document that the requirement applies to agent-generated code. Doing it ad hoc doesn't produce the consistent evidence trail CC8.1 calls for.

Third: deferring to the next audit cycle. The 2026 cycle is when auditors started asking directly about agents. An unaddressed finding in 2026 becomes a repeat finding in 2027, which is harder to close.

Checklist for your next audit prep sprint

## SOC 2 agent audit readiness

- [ ] Policy written: which environments permit agent sessions with what credential scope
- [ ] MCP server inventory collected: name, version, hash, approved/unapproved status
- [ ] MCP allowlist documented and enforced (MDM, policy, or technical control)
- [ ] Agent state paths (.claude/, .cursor/, .aider/, .codex/) in .gitignore across all repos
- [ ] Same paths in .npmignore / MANIFEST.in / .dockerignore for publishing repos
- [ ] CI prepublish gate exists and logs are retained
- [ ] Gitleaks or equivalent running in CI; reports saved per repo per quarter
- [ ] Agent grant log exists for each developer session touching prod-adjacent credentials
- [ ] SIEM rules account for agent session patterns; anomaly review log maintained
- [ ] Agent-generated PRs labeled or otherwise identifiable in code review records
- [ ] Second-reviewer requirement documented for agent-generated changes in security paths
- [ ] Data handling policy updated to cover model API call classification
- [ ] Evidence package assembled: grant logs, MCP inventory, CI gate logs, review records

Run this list before the audit window opens, not during it.

What this means for your stack

Treat this as a logging problem. You need session-scoped records of what the agent accessed, what it called externally, and what it produced. Your git history and CI logs already cover some of that. The missing piece for most teams is the credential-access layer: which secrets were in scope for a given agent session, and when.

A credential broker sitting between the agent and the underlying secret produces this record as a side effect. The broker knows which secret was requested, which session requested it, and when. An HMAC-chained audit log of those events is directly presentable as CC6.1 evidence. hasp is one working implementation: it holds secrets in a local encrypted vault, injects values into specific child processes at exec time, and writes a tamper-evident ~/.hasp/audit.jsonl that hasp audit --verify can validate on request. Source-available (FCL-1.0), local-first, macOS and Linux, no account required.

With or without a broker, the core requirement is the same. Agents reading ambient environment variables leave no credential-access trail. That absence is the finding. Build the trail before the auditor asks for it.