squidbrake

Guide

SOC 2 for AI agents: the change-management evidence auditors will ask for

By Pulkit Batra · · 3 min read

SOC 2 doesn't have an AI chapter, and it doesn't need one. If an AI agent changes production (a migration, a config change, a deleted bucket, a refund) that is a change, and the change-management control applies the same way it does to a human's pull request. Most teams running agents can't yet answer the first question an auditor will ask: who approved that?

In short

  • SOC 2 CC8.1 asks that changes be authorized, tested, approved and documented. An agent's changes count.
  • Separation of duties: the person running the agent shouldn't be the only approver.
  • You need a record of what the agent did, who approved it, and proof the record wasn't edited.
  • Squidbrake supports this evidence with a hash-chained log and a one-page evidence pack. Your auditor decides what it satisfies.

Why agents fall under change management

CC8.1 in the SOC 2 Trust Services Criteria covers authorizing, designing, testing, approving and implementing changes to infrastructure, data and software. Auditors usually test it by sampling changes and asking for the ticket, the approval and the deployment record. Pull requests with required reviews make that easy for code.

Agents break the pattern. A coding agent with cloud credentials can run terraform apply from a laptop. A support agent can issue refunds. An ops agent can flip a feature flag for one customer. None of these go through a pull request, and the only "approval" may be the same engineer clicking yes in a chat window.

What auditors will ask

From an agent's request to audit evidenceFive steps: the agent asks, a rule or a second person decides, the change runs with a copy kept, the decision is written to a hash-chained log, and an evidence pack summarises it. Each step answers an auditor question.EVERY RISKY CHANGE AN AGENT MAKES01Agent askstool + inputWhat changed?02Second personapproves or notWho approved it?03Change runscopy kept firstCan we undo it?04Hash-chainedlog entryWas it edited?05Evidence packone pageShow me.
The questions in italics are the ones an auditor asks about any production change. The record has to exist before they ask.
  • Which agents can change production, and with what credentials? An inventory and per-agent identity.
  • What changed? The tool, the input and the effect: rows deleted, resources destroyed.
  • Who approved it, and were they independent? Separation of duties: not only the person running the agent.
  • How do you know the log is complete and unaltered? Integrity of the record itself.
  • What happens when something goes wrong? Rollback, and the ability to stop agents quickly.

Designing controls that produce evidence

  1. Classify agent actions by reversibility. Reads and in-repo edits are low risk and can be authorized by policy. Deletes, infrastructure changes, money and outbound data need a person.
  2. Make the policy itself a controlled change. Keep the rules in a versioned file in the repo, so changes to what agents may do go through code review. This is your "authorized by policy" evidence.
  3. Require a second person for the risky set. Route by risk: finance approves refunds, the on-call approves infrastructure. Agent keys can never approve.
  4. Record every decision in a tamper-evident log. Squidbrake chains each record to the previous one by hash and signs checkpoints, so an edit or deletion shows up when the chain is verified, offline.
  5. Export the evidence on demand. squidbrake evidence --days 90 produces a printable one-page pack; CSV and JSONL exports carry the full detail.

How it maps

ControlWhat it asksEvidence from an agent checkpoint
SOC 2 CC8.1Changes authorized, approved, documentedEach change authorized by a versioned rule or approved by a person, with who, what and when
ISO/IEC 27001:2022 A.8.32Change managementThe same approval record, against a versioned policy file
ISO/IEC 27001:2022 A.8.15LoggingEvery tool call, decision and approval, hash-chained, exportable
EU AI Act Art. 12 and 14Record-keeping and human oversightRecords of agent actions; a person can hold, reject and stop them

This is how we map Squidbrake's records to these controls. It supports your evidence; your auditor decides what it satisfies. More on the security page.

Start before the audit window

Evidence has to exist for the whole period an auditor samples, often 3 to 12 months. Turning on logging the week before fieldwork leaves a gap. Run in shadow mode first if you're worried about disruption: every action is recorded from day one, and nothing is blocked until you decide to enforce.

FAQ

Does SOC 2 apply to AI agents?

SOC 2 applies to your system, and agents that change it are part of it. Changes an agent makes to production fall under the same change-management criteria (CC8.1) as human changes.

What evidence do auditors want for AI agent changes?

Typically: which agents can change production, a record of what each changed, who approved it, that the approver was independent, and that the log is complete and unaltered.

Is a tamper-evident log the same as tamper-proof?

No. Tamper-evident means any edit or deletion is detectable when the hash chain is verified. It does not prevent someone with database access from changing records; it makes the change visible.

Will Squidbrake make us SOC 2 compliant?

No product does that on its own. Squidbrake produces approval and audit-trail evidence for agent changes that supports your CC8.1 controls. Your auditor decides what it satisfies.

Try it on your own agents. pipx install squidbrake, then squidbrake connect all. Start in shadow mode: nothing is blocked in week one, you see what would have been. Quickstart · Benchmark · Book a demo