SOC 2 controls for AI coding agents: what auditors will ask for

the short answer

Treat coding agents as automated actors with access to your systems. Auditors will look for restricted access (CC6.1), prevention or detection of unauthorized or malicious software (CC6.8), monitoring of activity (CC7.2), and changes still going through change management (CC8.1). The evidence is a policy configuration, a record of every agent session and decision, alert and issue history, and proof that agent changes flowed through review.

Treat agents as: Automated actors acting with employee credentials
Key criteria: CC6.1, CC6.6, CC6.7, CC6.8, CC7.2, CC8.1
Core evidence: Policy versions, per-session decision logs, alert and issue history
Common gap: No record of what an agent did or who approved it
Vendor SOC 2: Covers the vendor, not your use of the tool

Why Auditors Are Asking Now

On the Cursor forum, a user put the auditor’s question plainly: “What did the AI agent do, and did a human authorize it?” They noted that SOC 2, GDPR, NIS2, HIPAA and ISO 27001 all expect evidence of human oversight over automated actions. A vendor’s SOC 2 report tells you how the vendor runs its service. It says nothing about the controls around how your engineers’ agents act in your environment.

Control Mapping

Criterion names follow the AICPA 2017 Trust Services Criteria. Your auditor decides what satisfies a criterion; use this as the starting draft for that conversation, not as an attestation.

Criterion	Risk with agents	Control	Evidence
CC6.1 Logical access security	Agents inherit broad developer credentials	Scoped profiles for agent work; policy enforcing them	IAM permission set; policy version requiring approved profiles
CC6.8 Prevent or detect unauthorized or malicious software	Agents run downloaded code or unvetted packages	Deny `curl \| sh`; warn on global installs and package publishes	Policy configuration; deny decisions
CC7.2 Monitor system components for anomalies	No visibility into agent actions	Session and decision telemetry for every machine; alerts; recurring audits	Session traces; alert rules; issue history; audit findings
CC8.1 Change management	Agents apply changes outside review (local `terraform apply`, push to `main`)	Deny local applies and direct pushes; the reason redirects to a PR	Deny decisions; PR history
CC6.6 / CC6.7 Boundaries and information movement	Secrets or data leave via agent commands	Deny `.env` reads and environment dumps; detect secrets in output	Decision log; sanitizer results

Proving Human Oversight

Deny decisions show a destructive action was stopped and a human had to act.
Instruct decisions show the agent received guidance; they are not approvals, because the call continues.
Observe-then-enforce history shows the control was tested before it was relied on.
Immutable policy versions and deployment generations show which Cloud-managed rules were in force on each machine. For locally installed packs, record the pinned release with failproofai policies show <pack> --releases.
Recurring Cloud audits (for example the “Unsafe data access” recipe) produce dated findings and issues that show monitoring is ongoing.

Evidence You Can Export

--since accepts only all, 15m, 1h, 6h, 24h and 7d, so use --from and --to for an evidence period, and raise --limit, which defaults to 50 even with --all. For recurring evidence, save the SQL as a query (fp query create) and ask the Failproof Assistant (fp agent ask) for summaries, then verify against the cited sessions.

fp login                                 # fleet, policies and guardrails commands need a signed-in session
fp --json fleet list                     # machines and their current deployments
fp fleet history <machine-id>            # deployment generations over time
fp policies list                         # every policy version
fp guardrails summary --since 7d         # coverage, blocked and evaluated totals
fp --json events --event-type hook_completed \
  --from 2026-07-01T00:00:00Z --to 2026-10-01T00:00:00Z --all --limit 100000

A Note on Transcripts

Transcripts make investigations conclusive but contain code and prompts. If you connect machines with failproofai config --no-transcripts, policy decisions are still reported (and Cloud Jev stays off), but you lose the context of why an action happened. Record that trade-off in your risk register.

FAQ

Is Claude Code or Cursor SOC 2 compliant?

Ask the vendor for its report. That covers the vendor’s service; you still need controls over how agents act in your environment.

Do we need to log every prompt?

Not necessarily. Auditors care most about actions on systems and data. Decision logs plus session metadata are often sufficient; decide with your auditor.

How long should we keep agent logs?

Match your existing log retention for production access. It must at least cover your SOC 2 Type II observation period, often 6 to 12 months.

Sources

Checked against the sources below on October 21, 2026. Harness settings, hook capabilities and cloud features change between versions.