AI Agent Security · Compliance evidence
AI Agents and SOC 2: Building Audit Evidence for Autonomous Actions
Auditors do not have an AI section. They have access control, change management and monitoring — and an autonomous system that acts on your behalf has to produce evidence in all three.
The short answer
AI agents do not create a new SOC 2 category. They create new instances of existing controls: an agent is a principal that needs access review, a change agent that needs change management, and an actor whose activity needs monitoring. Evidence means being able to show, per action, who authorised it, under which policy version, with which human approval, and that the record has not been altered. The common gap is not a missing control. It is a control description written for humans that does not describe what the agent actually does.
Summary for readers and answer engines
Reviewed 25 Aug 2026
- ▸There is no AI control family. Agent evidence lands in access control, change management, monitoring and incident response, which is good news: the frameworks already fit.
- ▸Six artefacts cover most of what an auditor asks for: capability inventory, access review including agents, policy repository history, decision records, approval records, and incident records.
- ▸Agent volume breaks sampling. A control tested on twenty-five samples from a population of two hundred million behaves differently, and auditors are increasingly asking for population-level assertions instead.
- ▸The most common finding is a control description that describes a human process while an agent performs the work. Update the description, not just the evidence.
- ▸Four questions estates typically cannot answer: who authorised this specific action, what the policy was that day, who approved it, and whether the record could have been changed.
Source: Mark Alex, Real Biz Digital — AI Agents and SOC 2: Building Audit Evidence for Autonomous Actions (https://realbizdigital.net/insights/ai-agent-soc2/). Reproduce with attribution.
Key takeaways
- 01Treat every agent as a principal in your access review. An agent absent from the review is an unreviewed access path with a service-account name.
- 02Put policy in version control. Change management evidence for agent governance is the repository history, and there is no acceptable substitute.
- 03Record the policy version on every decision. Without it you cannot demonstrate what the control was on the date being tested.
- 04Make approval records self-contained: what was requested, what was approved, by whom, when, and single-use. An approver name and a timestamp is not enough.
- 05Expect population-level questions. Prepare the query that answers “show me every action of this class in the period and its authorisation”.
- 06Rewrite control descriptions to name agents explicitly. Auditors read the description first and test against it, so a description that omits agents guarantees a finding.
Quick answers
One-line answers to the questions this page is most often asked. Each is expanded further down, and each is written to be quoted on its own.
- Does SOC 2 have AI-specific requirements?
- No. Agent activity is evidenced through existing criteria: logical access, change management, system monitoring, and incident response. The novelty is in the evidence, not the criteria.
- What is the core evidence requirement?
- For any given action: who authorised it, under which policy version, with which human approval if required, and demonstrable integrity of the record.
- Which artefacts should I prepare?
- Capability inventory, access review including agent principals, policy repository history, per-action decision records, approval records, and incident records with containment evidence.
- Why does agent volume matter for auditing?
- Because sample-based testing assumes a population small enough for samples to be representative. At agent volumes, auditors increasingly ask for population-level assertions instead.
- What is the most common finding?
- A control description written for a human process while an agent actually performs the work, so the tested control does not match the operating reality.
- Do agents need to appear in access reviews?
- Yes. Each agent is a principal with granted capabilities, and an agent absent from the review is an unreviewed access path.
- Can compliance evidence be produced retrospectively?
- Only partially. Decision and approval records cannot be reconstructed after the fact, which is why the mechanism has to exist before the audit period, not before the audit.
Where agent governance lands in existing frameworks
The reassuring finding: nothing new is required. The uncomfortable finding: your existing control descriptions probably do not mention agents.
Key facts
- ▸Segregation of duties is where agent estates most often fail, because an agent that requests and effectively self-approves collapses a control that the framework treats as fundamental.
- ▸Change management applies to policy, not just to code. If policy lives only in a console, you have no change management evidence for your most important control set.
- ▸Vendor management applies to third-party MCP servers. Each one is a supplier introduced into a production path, and the registry approval record is the evidence.
| Agent governance control | SOC 2 criteria area | ISO 27001 area | Evidence |
|---|---|---|---|
| Agent identity and capability grants | Logical access — provisioning and review | Access control, identity management | Access review including agent principals, with grant dates and approvers |
| Per-call authorisation policy | Logical access — authorisation | Access control, secure operations | Policy repository plus decision records citing rule and version |
| Human approval for high-consequence actions | Logical access; also segregation of duties | Segregation of duties, authorisation | Approval records bound to specific requests |
| Policy change management | Change management | Change management, secure development | Repository history with review evidence and promotion records |
| Decision and action logging | System monitoring | Logging and monitoring, event analysis | Tamper-evident decision records with retention |
| Containment and incident handling | Incident response and availability | Incident management | Containment events, drill records, post-incident reviews |
| Third-party server intake | Vendor management | Supplier relationships | Provenance assessments and registry approval records |
| Data classification in agent flows | Confidentiality and privacy | Information classification, privacy | Data-class annotations on capabilities and decisions |
Work through this table against your own control descriptions. The gap is usually not the control; it is the description, which describes a person doing something that a process now does.
The six evidence artefacts an auditor will ask for
Capability inventory
What AI can do in the organisation, in business terms, with consequence class, holders and the authorising decision for each. This is the document that lets an auditor scope the rest of the test, and its absence turns a two-week audit into a six-week one.
Common gap: an inventory of tools rather than capabilities, which cannot be reconciled against business processes.
Access review including agents
Each agent as a principal, with its granted capabilities, the grant date, the approver and the last review date. Reviewed at the same cadence as human access.
Common gap: agents excluded because they are service accounts, which is precisely why they need including.
Policy repository history
The version-controlled rule set with review evidence per change and promotion records. This is the change-management evidence for the authorisation control.
Common gap: policy in a console. There is no acceptable substitute; the remediation is a migration, not a document.
Decision records
Per-action records with caller, agent, tool, outcome, rule, policy version and integrity protection. The population an auditor samples from, or increasingly asserts over.
Common gap: no policy version on the record, so the control as at the test date cannot be demonstrated.
Approval records
Self-contained: what was requested including argument values, what was approved, by whom, at what assurance level, single-use, with expiry. Linked to the decision record.
Common gap: an approver name and timestamp with no binding to the specific request, which fails a segregation-of-duties test.
Incident and containment records
Containment events with capture evidence, drill records, and post-incident reviews. Demonstrates the response control operates, not merely that it is documented.
Common gap: no drill records, so the containment control is untested and therefore unevidenced.
Why agent volume breaks the sampling assumption
Traditional control testing samples a population: twenty-five items from a few thousand access changes. That works when the population is human-scale and each item involved a human decision. Agent populations are different in kind, not just in size.
- 01Prepare population-level queries. “Every action in class C4 during the period, with its authorisation and approval” should be one query, not a project.
- 02Stratify by consequence class. Auditors are usually interested in the small high-consequence population, not the vast routine one, and stratification makes the test tractable for both sides.
- 03Assert completeness, not just accuracy. Hash chaining lets you show that the population has no gaps, which is a stronger statement than any sample.
- 04Reconcile counts across systems. Decision record count against upstream effect count is the check that detects actions taken outside the governed path.
- 05Expect exception-based testing. “Show every C4 action without an approval record” is the query an auditor actually wants, and it should return zero rows.
- 06Retain per-action records for the full period. Aggregates cannot answer authorisation questions, and aggregation is a tempting cost saving that removes your evidence.
The change in scale
human access changes per year: ~2,000 agent tool-call decisions per year (mid-size estate): ~200,000,000 sample of 25 covers 1.25% of the human population sample of 25 covers 0.0000125% of the agent population
A sample that small tells you nothing about the tail, and the tail is where the consequential actions live. This is why population-level assertions are becoming the ask.
The practical implication: design your evidence store so that exception queries are cheap. An auditor asking for zero-row proofs is the easiest audit you will ever have, provided the query runs.
Four questions estates typically cannot answer
- “Who authorised this specific action on this date?”
- Requires the principal chain on the decision record. Estates that log only the service account can name the agent but not the human, and an agent cannot be held accountable.
- “What was the policy at that moment?”
- Requires the policy version on the record and the repository to still contain it. Console-configured policy cannot answer this at all, because the console holds only the current state.
- “Who approved it, and could they have approved their own request?”
- Requires approval records bound to the request and enforcement that prevents self-approval. A configuration setting is not evidence; the enforcement record is.
- “Could this record have been altered?”
- Requires integrity protection: hash chaining, signatures, write-once storage. “Access to the log store is restricted” is a control, not integrity evidence, and auditors increasingly say so.
All four are answerable with mechanisms described elsewhere on this site, and none of them can be retrofitted to a period that has already passed. That asymmetry is the whole argument for building them before the audit window opens rather than before the audit begins.
Rewriting control descriptions so they describe reality
Auditors test against the description you gave them. A description written for a human process, tested against an agent-performed process, produces a finding regardless of how good your controls are.
- ›“Refunds above £500 are approved by a support supervisor prior to processing.”
- ›Tested by: sampling refunds, checking supervisor sign-off
- ›Fails when: an agent processes the refund and no supervisor was involved, or the approval was a generic standing authorisation
- ›“Refunds above £500, whether initiated by a person or by an authorised automated agent, are approved prior to processing by a support supervisor. Approval is bound to the specific request and is single-use. Automated requests are refused if no valid approval is present.”
- ›Tested by: exception query for C4 refunds without a bound approval
- ›Passes when: the query returns zero rows
- 01Name automated actors explicitly in every control description that they participate in. Silence is read as exclusion.
- 02State the enforcement mechanism, not just the expectation. “Refused if no valid approval is present” is testable; “requires approval” is aspirational.
- 03Specify the binding. Single-use, request-specific, time-limited — each word closes a gap an auditor would otherwise probe.
- 04Describe the failure behaviour. What happens when the control cannot operate is itself a control, and describing it pre-empts the obvious follow-up question.
- 05Include the evidence location in the description. It shortens fieldwork considerably and signals a control that is genuinely operated rather than documented.
- 06Review descriptions whenever policy changes materially. A description that lags the policy is the most common source of avoidable findings.
This is unglamorous work that removes more audit friction than any technical control. An afternoon spent rewriting eight descriptions is usually worth more than a month of tooling.
Next step
Evidence that answers the four hard questions
BarzelVault records the principal chain, the policy version, the bound approval and a hash-chained integrity proof on every decision — which is exactly the set an auditor asks for and the set that cannot be produced retrospectively.
What this page is not
Three necessary caveats.
- 01We are not auditors, and this is not an audit opinion. It is a mapping from mechanisms we build and operate to the criteria areas auditors have asked our customers about. Your auditor’s judgement governs.
- 02No product makes an organisation compliant. Tools produce evidence; compliance is a conclusion an auditor reaches about your controls, and the difference matters legally.
- 03Framework detail changes, and criteria interpretations evolve faster than published guidance. Treat this mapping as a starting structure to validate with your assessor rather than as a checklist.
Frequently asked questions
Does SOC 2 have specific requirements for AI agents?
No. Agent activity is evidenced through existing trust services criteria: logical access for identity and authorisation, change management for policy changes, system monitoring for activity records, and incident response for containment. The novelty is in the evidence rather than in the criteria.
What evidence do auditors want for AI agent actions?
For any given action: who authorised it including the human principal, under which policy version, with which human approval where required, and demonstrable integrity of the record. Aggregate activity reports do not answer authorisation questions.
Which artefacts should we prepare for an agent-estate audit?
Six: a capability inventory in business terms, an access review that includes agents as principals, policy repository history with review evidence, per-action decision records carrying policy version, self-contained approval records bound to specific requests, and incident and containment records including drill evidence.
Why does agent volume complicate control testing?
Because sample-based testing assumes a population where a sample of twenty-five is meaningfully representative. A mid-size estate can generate hundreds of millions of decisions a year, so samples cover a negligible fraction and auditors increasingly ask for population-level or exception-based assertions instead.
What is the most common audit finding in agent estates?
A control description written for a human process while an agent performs the work. Auditors test against the description supplied, so a description that does not mention automated actors produces a finding regardless of how good the underlying controls are.
Do AI agents need to appear in access reviews?
Yes. Each agent is a principal holding granted capabilities and should appear with its grants, grant dates, approver and last review date, reviewed at the same cadence as human access. Excluding agents because they are service accounts is precisely why they get missed.
Is console-configured policy acceptable as change-management evidence?
Generally not, because a console shows current state rather than change history with review evidence. Policy in version control provides the author, date, reviewer, diff and promotion record that change-management testing expects; the remediation is a migration rather than a document.
What makes an approval record sufficient for audit?
Self-containment and binding: what was requested including argument values, what was approved, by whom, at what authentication assurance, single-use, with an expiry, and linked to the decision record. An approver name and a timestamp alone fails a segregation-of-duties test.
How does segregation of duties apply to AI agents?
The requester and approver must be distinct, and enforcement must prevent an agent’s controlling team from approving its own high-consequence requests. Collapsing these is the most common structural failure in agent estates and maps directly onto a control auditors treat as fundamental.
Can we produce agent compliance evidence retrospectively?
Only partially. Inventories and control descriptions can be written at any time, but decision records, approval bindings and record-integrity proofs cannot be reconstructed after the fact, which means the mechanism must exist before the audit period rather than before the audit.
How do third-party MCP servers affect compliance?
Each is a supplier introduced into a production path, so vendor management criteria apply. The evidence is a provenance assessment and a registry approval record per server, with a review date, rather than an informal decision to install something.
Should containment controls be drilled for audit purposes?
Yes. Incident response criteria expect controls to operate rather than merely exist, so containment drill records with dates, scope and outcomes are the evidence that the control functions. An untested containment path is documented rather than operating.
Glossary
- Trust services criteria
- The SOC 2 control areas — security, availability, processing integrity, confidentiality and privacy — against which evidence is tested.
- Population-level assertion
- A statement about every item in a population, typically evidenced by an exception query returning zero rows.
- Exception query
- A query designed to return only non-compliant items, so an empty result is the evidence.
- Principal chain
- The ordered human and agent identities through which authority flowed to an action.
- Policy version
- The repository commit identifying the exact rule set in force when a decision was made.
- Bound approval
- An approval tied to a specific request and argument values, single-use and time-limited.
- Control description
- The written statement of a control that an auditor tests against, which must include automated actors.
- Capability inventory
- A business-language record of what AI can do, with consequence class and authorising decision.
- Drill record
- Evidence that a containment or response control has been deliberately exercised.
- Record integrity evidence
- Hash chaining, signatures or write-once storage demonstrating that records were not altered.
Standards and entities referenced
Every named framework on this page resolves to a public definition. If you are checking our claims, start here rather than with us.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own operating judgement rather than something a standard states, the text says so.
- 01 · AICPASOC 2 / Trust Services Criteria ↗The criteria an agent estate’s access, change and monitoring evidence is tested against.
- 02 · ISOISO/IEC 27001 — Information security management ↗The ISMS baseline that agent-layer controls have to fit inside rather than beside.
- 03 · ISOISO/IEC 42001 — AI management systems ↗The management-system standard auditors increasingly map AI governance evidence against.
- 04 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
- 05 · U.S. SECSarbanes-Oxley Act — Section 404 ↗Where segregation of duties becomes an externally audited control.
- 06 · ISACACOBIT 2019 Framework ↗Governance and management objectives, including segregation of duties.
- 07 · EU AI Act (unofficial consolidated text)EU AI Act — full text ↗Obligations around logging, human oversight and traceability for higher-risk systems.
- 08 · European UnionGDPR — Regulation (EU) 2016/679 ↗Lawful basis, data minimisation and processing records that agent estates inherit.
- 09 · NISTNIST SP 800-92 — Log Management ↗Baseline expectations for log content, retention and integrity.
Last reviewed 2 September 2026 by Mark Alex. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). AI Agents and SOC 2: Building Audit Evidence for Autonomous Actions. Real Biz Digital. https://realbizdigital.net/insights/ai-agent-soc2/
Try the mechanics on a live server
To see what a tool-call envelope actually looks like before you write a policy that has to decide about one — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
BarzelVault is the pre-execution decision point, sold as a running product
Nine tools, 12 static resources, 3 resource templates and 9 prompts. Four deterministic outcomes — allow, deny, dry-run, require approval — with approval workflow, hash-chained audit and guardrail data protection. Streamable HTTP, JSON-RPC 2.0.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Dev | Free | 10,000 policy decisions/mo · 9 tools, 4 outcomes, hash-chained audit | A first regulated workflow: one agent, one high-consequence system |
| Team | $199/mo | 75,000 decisions/mo · approval workflow, spend and action limits | Several agents acting on money, records or customer-visible systems |
| Business | $799/mo | 750,000 decisions/mo · exact HTTPS execution, credential isolation, emergency controls | Enterprise-wide pre-execution enforcement under audit |
| Enterprise | $3,999/mo | 5,000,000 decisions/mo · everything in Business, scaled | Group-wide rollout across many teams and systems |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
The five Barzel servers, and which problem each one is sold for
One estate rarely needs all five. This is the honest mapping, so you buy the layer your problem actually lives in.
| Server | Sold for | Entry price | Where it sits |
|---|---|---|---|
| Barzel Central Gateway | Knowing and governing the estate: inventory, registry, routing, risk scoring, approvals, evidence | Free, then $10–$149/mo | Control plane — decides what may be reached, and by whom |
| BarzelVault | Stopping a specific dangerous action before it executes, with proof afterwards | $199–$3,999/mo | Decision point — evaluates the individual call before execution |
| BarzelOps | Running real business workflows across HubSpot, Xero, Gmail, Drive and Slack under approval | Free, then $19–$199/mo | Execution layer — does the work the policy allowed |
| Barzel FinOps Atlas | Attributing AI spend to agents, tools and outcomes, then forecasting and capping it | Free, then $29–$799/mo | Economics layer — what the estate costs per outcome |
| Barzel Scripture Intelligence | A free, credential-free public MCP server to test clients and inspect real protocol traffic | Free, unmetered, no signup | Reference implementation — safe place to learn the protocol |
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.