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 vulnerability detection, incident response, and change management for production and production-adjacent systems. If an agent can commit code, run migrations, or touch infrastructure config, its actions fall under the same change-management 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 CC7's change-management control 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.

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. 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.

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, CC7.
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 doesn't enforce anything. It's detective, not preventive. If your control language requires blocking a class of action, an observe-only tool covers half the control at most.
• 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 CC7 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

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.