SOC 2 for AI coding agents: mapping CC4 and CC7 to agent activity

No SOC 2 criterion says "AI agent" anywhere in the text, and that's exactly the trap. Auditors don't need a new control to ask about agentic tooling — they apply the criteria you already have. CC4 (monitoring activities) and CC7 (system operations) were written for changes to systems, and an AI coding agent acting under a developer's credentials is still a change to a system. This post maps where agent activity actually lands in SOC 2, what else changed in the 2026 compliance landscape, and what an evidence checklist for agent activity looks like in practice.

TL;DR

Where AI coding agents actually land in SOC 2

SOC 2 is built on the AICPA's Trust Services Criteria (TSC), organized under nine Common Criteria families (CC1 through CC9). Two of them do most of the work when an AI coding agent enters the picture:

• CC4 — Monitoring Activities. The organization selects, develops, and performs ongoing evaluations to confirm that controls are present and functioning. An agent that can read, write, or execute without a human reviewing each action is a gap in that evaluation unless something else is watching it.
• CC7 — System Operations. Covers detecting vulnerabilities, configuration changes and anomalies, evaluating security events, and responding to incidents. Change management proper sits in the neighbouring family, CC8 (see below). If an agent can commit code, run migrations, or touch infrastructure config, its actions fall under the same expectations as a human engineer's.

Neither criterion cares whether the hands typing the command belong to a person or an agent acting on that person's behalf. An auditor testing the change-management control (CC8.1) will ask "how do you know what changed and who approved it" regardless of which tool produced the diff. If your answer only covers human-initiated PRs and silently excludes whatever an agent did in an editor session, that's the gap an auditor will find — not because AI is named anywhere, but because the control's actual scope was never about the tool.

This mapping is a practical read of how auditors are applying existing criteria to agentic tooling, not a claim that the AICPA has published AI-specific guidance — it hasn't, as of this writing.

A note on criterion numbers

The AICPA's 2017 Trust Services Criteria (with revised points of focus, 2022) are the authoritative text, and the full document sits behind a free account. Secondary guides describe the structure consistently enough to map agent activity: CC4.1 is about ongoing and separate evaluations of whether controls are present and functioning; CC7.1 concerns detecting configuration changes that could introduce vulnerabilities; CC7.2 concerns monitoring system components for anomalies and security events; and CC8.1 covers the change lifecycle, from authorizing and designing through testing, approving and implementing changes to infrastructure, data and software (Bright Defense's summary is one example). Guides differ on small details, and wording changed with the 2022 points of focus, so check the criteria text your auditor uses. An earlier version of this post folded change management into CC7; it belongs in CC8.1, and CC8 should be in scope for agent-authored changes too.

How an agent session maps to the criteria

A concrete walk-through helps. Suppose an agent, acting under a developer's credentials, edits a migration, runs it against a staging database and opens a pull request.

1. The edit and the pull request are changes to software. CC8.1 asks whether the change was authorized, tested and approved before implementation. A pull request with a required human reviewer answers this for the code, provided the reviewer reviewed the diff itself.
2. The command that ran the migration is an action on a system component. CC7.1 and CC7.2 ask whether you can detect configuration changes and anomalous activity. If the only record is the developer's shell history, the agent's tool calls are invisible to that detection.
3. A flagged event, for example a read of a credential file, belongs to the security-event evaluation and incident-response criteria in CC7. You need to be able to say who looked at it and what they decided.
4. The review of the monitoring itself is CC4.1: someone periodically confirms that the monitoring still covers the tools in use.

The point is that no step needs a new control. Each needs the existing control to include the agent's actions in its evidence.

The rest of the 2026 backdrop

SOC 2 isn't the only framework moving. A few developments worth tracking alongside it, without conflating them:

• ISO/IEC 42001:2023 is the dedicated AI management system standard — it governs how an organization identifies AI risk and makes lifecycle decisions, not whether specific controls operated correctly over a period. It's a different instrument from SOC 2, and some enterprise buyers now ask about both.
• OWASP's Top 10 for Agentic Applications, published in December 2025, gives auditors and security teams a shared vocabulary for agent-specific risks (excessive agency, tool misuse, memory poisoning) that didn't exist in earlier OWASP lists.
• The EU AI Act's high-risk obligations (Articles 8-17, 26, 27, 73) activate August 2, 2026, but generally don't reach internal developer tooling directly — see the full breakdown in EU AI Act and AI coding agents.
• Colorado's AI law has been a moving target. Law-firm summaries (Holland & Knight, JD Supra) report that SB 26-189 repeals and reenacts the earlier law, drops the mandatory risk-management programs and annual impact assessments, and instead requires disclosures before use, explanations of adverse outcomes and a path to human review where commercially reasonable. One summary says enforcement depends on the attorney general completing rulemaking; check that against the statute. In short: SB 24-205 was delayed from its original February 2026 date to June 30, 2026, then paused by a federal court in April 2026, then effectively replaced when Colorado signed SB 26-189 on May 14, 2026 — a substantially revised framework that takes effect January 1, 2027. If a piece of content tells you a Colorado AI Act deadline lands anywhere in 2026, it's describing a law that has since been replaced.

None of this changes the SOC 2 mapping above. It does mean an evidence package built today should be legible to more than one framework, since the same underlying question — "what did this system do, and who is accountable for it" — recurs across all of them.

Questions to settle before the audit window opens

Auditors differ, but a few decisions are cheaper to make early than to explain later:

• Scope statement. Does your system description mention AI coding tools that can change in-scope systems? If agents touch only a laptop sandbox, say so and say why that is out of scope. If they can reach production credentials, they are in.
• Credential model. Which credentials does an agent inherit from the developer, and could a narrower one be issued? Narrower credentials shrink what access and operations testing has to cover.
• Approval path. Is every agent-authored change reviewed by a human who sees the diff before merge? Write the rule down, and confirm branch protection enforces it.
• Third-party vendors. Agent vendors process your code and prompts. Your vendor-management process should include them and record what you reviewed.
• Exceptions. If a developer ran an unapproved agent, how is it found and recorded? An exception log with a documented response is better evidence than a claim that none occurred.

What an auditor actually tests

A CC4/CC7 walkthrough for agent activity tends to ask the same handful of questions, regardless of auditor:

1. Can you show me what an agent did to this repository last quarter? — tests completeness, not just existence, of monitoring.
2. Who approved this change, and was a human in the loop before it landed? — tests change management, CC8.1.
3. How would you detect if an agent read or exfiltrated a credential? — tests CC7's incident-detection sub-criteria.
4. How long do you retain this evidence, and who can alter it? — tests CC4's evaluation and the general integrity expectation running through both families.
5. What tools were in scope, and which weren't instrumented? — auditors increasingly ask this explicitly, because "we don't watch Cursor sessions" is now a specific, callable-out gap rather than an assumed non-issue.

Where Beam fits, and where it doesn't

Beam is a local-first observability layer for AI coding agents — it watches what Claude Code, Codex, Cursor, and similar tools do on a developer's machine, and gives you a record to review. It is not a compliance product and does not claim to satisfy any SOC 2 criterion by itself.

What it can supply toward an evidence package, per its own documentation:

• A per-event activity record with source_agent, session_id, project_path, and event_type — the attribution and evidence pieces a CC4/CC7 walkthrough asks for, normalized across Claude Code hooks, direct CLI pipes, Numbat imports, and OTLP/HTTP JSON.
• A reviewed-status flag on flagged events, so the record shows a human looked, which is the kind of trail CC4's "ongoing evaluation" language expects to see.
• An export — a JSON container of event, scan, and review files plus SHA-256 hashes — that an auditor can be handed as raw evidence rather than a summarized dashboard.

The honest limits, stated the way an auditor would eventually find them anyway:

• Beam's deny is hook- and extension-based, not fail-closed. If your control language requires kernel or API-path blocking, pair Beam with that layer.
• The export's hashes prove internal consistency, not authenticity or completeness. They don't establish chain of custody.
• Coverage depends on instrumentation. /agents reports existence checks on common hook/config locations, not that a hook is live — absence of events isn't evidence of absence of activity.
• Retention is bounded to the latest 10,000 events and 500 reports, and pairing is single-user local, not fleet-managed — not yet a substitute for enterprise-wide evidence retention.

A practical evidence checklist

1. Name every agent in scope — Claude Code, Cursor, Codex, any custom agent — before an auditor asks. An unnamed tool is an unscoped gap.
2. Record attribution at the event level, not just "someone on the team used an AI tool this quarter."
3. Decide your retention window before an incident, and write down the actual cap, not an aspirational one.
4. Keep raw events, not summaries, for anything you'd hand an auditor — a risk score without the underlying command won't be accepted as evidence.
5. Review flagged events on a cadence and record that review, so CC4's "ongoing evaluation" has something to point to.
6. Document what isn't instrumented. A written list of uncovered tools is a smaller finding than an auditor discovering the gap themselves.
7. Map your evidence to more than one framework where you can. The same event log that answers a CC8 change-management question is also what ISO/IEC 42001 asks for on the AI-lifecycle side.

Summary

SOC 2 doesn't need an AI-specific criterion to reach your coding agents — CC4 and CC7 already do the job, because they were written around systems and changes, not around who or what produced them. The practical work is building one attributed, retained, human-reviewed record across every agent your developers actually use, and being honest with your auditor about what that record does and doesn't prove.

Related reading

• AI compliance and regulation for agent activity: what auditors need
• EU AI Act and AI coding agents: timeline, GPAI, and logging
• What is AI agent monitoring?
• AI agent security: securing coding assistants
• Enterprise AI coding agent rollout checklist
• AI agent security incidents: a timeline
• Monitor versus block for AI agents
• OWASP Top 10 for Agentic Applications 2026

Regulatory summaries are general information, not legal advice, and reflect public reporting as of September 23, 2026 — the Colorado AI Act's status in particular has changed multiple times in 2026 and may change again. Beam capabilities reflect the Sentinel collector v0.1 README as of this writing.