SOC 2 Evidence for AI Agents: What Auditors Actually Ask For

SOC 2 Evidence for AI Agents: What Auditors Actually Ask For

If you've shipped an AI agent into production and a customer's security team has started sending you questionnaires, you already know the shape of what's coming: SOC 2. And you've probably discovered the uncomfortable part — SOC 2 is not a document exercise. It's an *evidence* exercise. An auditor doesn't grade your intentions; they ask you to prove, run by run, that your controls actually operated.

That's manageable when the thing under audit is a CRUD app with human users clicking buttons. It gets awkward when the thing under audit is an autonomous agent that calls tools, writes to a database, sends email, and moves money on its own — often faster than any human reviews it. This post is about what evidence an agent actually needs, where the usual answers fall short, and how to make the evidence a byproduct of running the agent instead of a fire drill the week before the audit.

This is the practical, agent-specific companion to [Signed Receipts vs Trace Logs](/blog/signed-receipts-vs-trace-logs-agent-audit-trail). If you want the underlying argument for *why* a signature beats a log line, start there. If you want to know *what an auditor will ask an agent to produce*, keep reading.

SOC 2 in one sentence for engineers

SOC 2 evaluates whether your systems meet the Trust Services Criteria — Security (always), plus optionally Availability, Confidentiality, Processing Integrity, and Privacy. A Type II report is the one buyers actually want, and it's the demanding one: it says your controls didn't just exist on paper on one day, they *operated effectively over a period* — typically three to twelve months.

"Operated effectively over a period" is the whole ballgame. It means the auditor samples time. They pick dates. They say: *show me what the agent did on March 3rd, who authorized it, and prove this record is the real one.* Your ability to answer that — cleanly, for any day in the window — is what passes or fails.

The four questions an auditor asks an agent

Strip away the framework language and almost every agent-relevant control reduces to four questions:

1. What did it do? A complete, per-action record of the operations the agent performed.
2. Who authorized it? The scope or authority each action ran under — not just that *something* ran, but that it ran within the permissions it was supposed to have.
3. When? A trustworthy timestamp bound to the action, not a mutable column next to it.
4. Can you prove this record is real? Evidence that the record wasn't edited, backdated, or fabricated after the fact.

Map those to the Trust Services Criteria and you're touching the CC7 (system monitoring), CC6 (logical access), and CC8 (change management) common criteria, plus Processing Integrity if you carry that category. But you don't need to memorize control numbers. You need a system that can answer those four questions for any run in the audit window, on demand.

Why "we have logs" is a weak answer

The reflex is: *we log everything — LangSmith traces, OpenTelemetry spans, a structured logger in the agent loop.* That covers question 1 and question 3 in a debugging sense. It falls apart on question 4, and question 4 is the one an auditor cares about most.

A trace log has three properties that make it poor audit evidence:

• It's self-narrated. The agent writes down what it thinks it did. The record and the thing being recorded come from the same system.
• It's mutable. A log line is a row in a table or a line in a file. Anyone with write access can add, edit, or delete it, and the surrounding logs won't reveal that it happened.
• It doesn't travel. Export a trace, hand it to an auditor or a customer, and it's just text. Nothing in the artifact ties it back to the system that produced it. Text can be typed.

An auditor's entire job is professional skepticism. "Trust our logs" is precisely the answer the process is designed to distrust — because the logs are produced by the system under examination and could have been changed. You can raise the bar with append-only or WORM storage, and you should. But immutable storage proves *nobody deleted a row in this store*; it does not prove *this record was produced by that agent under that authority*, and it still doesn't travel. You end up assembling evidence by hand — screenshots, log exports, access-control config dumps — in the week before the audit. Every year.

What strong agent evidence looks like

Strong evidence has a different shape: it is generated automatically, per action, and it is verifiable by someone who doesn't trust you. That's a [signed receipt](/blog/signed-receipts-vs-trace-logs-agent-audit-trail). A receipt binds together, in one signed payload:

• What happened — the action, its inputs, and its result (send_email accepted by the mailbox; a tool call and the row it wrote; post_tweet → HTTP 201).
• Who did it — which agent, under which scope. The receipt records the *delegated authority* the action ran under.
• When — a timestamp inside the signed payload, not a column beside it.
• A signature over all of the above, using a key the acting system controls.

Because it's signed, it's tamper-evident: change the record and the signature no longer verifies; fabricate a receipt for an action that never happened and you can't, because you don't hold the key. Whoever you hand it to verifies the signature against a public key — *without trusting you*. The proof travels with the artifact.

Now re-read the four questions. A signed receipt answers all four in a single artifact, and answers question 4 — the hard one — by construction rather than by policy.

Access control is a control too — and it needs evidence

SOC 2's logical-access criteria (CC6) want proof that the agent could only touch what it was supposed to. This is where a lot of agent deployments quietly fail: the agent runs with a broad database credential or an over-scoped API key, and "we restrict access" is a claim with no evidence behind it.

The fix is to scope the access *and* record the scope. On a2a cloud, agents act through [scoped grants](/blog/scoped-grants-agent-delegation), and the access model is built so an agent gets its own database rather than a shared production credential — see [How to Give AI Agents Database Access Without Handing Over Production](/blog/give-ai-agents-database-access-without-handing-over-production). The payoff for the audit: the same receipt that says *what* the agent did also records the *scope it did it under*. Your access control isn't just configured — it's evidenced on every run.

SOC 2 and the EU AI Act are the same muscle

If you sell into Europe, you'll meet a parallel requirement from a different direction. The EU AI Act's Article 12 requires high-risk AI systems to automatically record events over the lifetime of the system, at a level that makes the system's functioning traceable. That's the same demand SOC 2 makes — a durable, attributable, defensible record — arriving as law instead of a customer questionnaire. We wrote about treating it as [a query rather than a quarter-long scramble](/blog/eu-ai-act-compliance-first-class). Build the evidence layer once, correctly, and you satisfy the auditor and the regulator with the same artifact.

Make evidence a byproduct, not a project

The teams that dread audits are the ones for whom evidence is a *project* — assembled by hand, after the fact, under deadline. The teams that don't are the ones for whom evidence is a *byproduct* — emitted automatically as the system runs, so "show me March 3rd" is a lookup, not an archaeology dig.

That's the design goal on a2a cloud. Every agent you deploy gets a managed Postgres database, an MCP server, an API, a frontend — and signed receipts for its runs, on by default. You don't wire up a signing pipeline; it's part of the runtime. We dogfood it: [our entire go-to-market is an agent on a2a cloud, and every action it takes leaves a signed receipt](/blog/our-gtm-is-an-agent-signed-receipt).

If your agent is going to have to answer *what did it actually do* — to an auditor, a customer's security team, or a regulator — start with one whose answer is verifiable:

• [Deploy a LangGraph Agent in 60 Seconds](/blog/deploy-langgraph-agent-60-seconds) — Postgres, MCP, and signed receipts from the first run.
• [Signed Receipts vs Trace Logs](/blog/signed-receipts-vs-trace-logs-agent-audit-trail) — the underlying case for why a signature beats a log.
• [Give AI Agents Database Access Without Handing Over Production](/blog/give-ai-agents-database-access-without-handing-over-production) — scope the access, then have the receipts to prove it stayed scoped.

SOC 2 doesn't ask you to trust your agent. It asks you to prove what it did. Build on a runtime where the proof is already in the box.