SOC 2 in the Age of Agents: What Your Auditor Has Not Figured Out Yet
SOC 2 was designed in an era when systems were operated by humans and changes to those systems were made by other humans. The control framework reflects this. The trust services criteria assume that access decisions are made by named individuals, that change management is conducted by tracked teams, that monitoring catches anomalies produced by human actors. The auditor’s procedures sample human workflows: who provisioned this account, who approved this deployment, who reviewed this change.
The framework has held up reasonably well through the past two decades. The trust services criteria are sound principles. The audit procedures have evolved. The framework now needs to evolve again, because the population of actors operating inside enterprise systems has changed materially.
A non-trivial fraction of the changes in our clients’ production environments in 2026 are now made by agents. Some of those agents are acting on behalf of named humans. Others are acting autonomously on long-running schedules. Others are acting in response to events whose causes trace back to other agents. The auditor’s mental model – name a human, trace an action to them – does not bind cleanly to this population.
We are not predicting that SOC 2 is obsolete. We are saying that the framework is, in practice, asking the wrong questions about the parts of the system that matter most, and the auditors are not yet asking the new questions because the new questions have not been ratified by AICPA guidance. There is a gap. Companies that pretend the gap does not exist are accruing a different kind of risk than the one their compliance program was designed to detect.
The Specific Mismatches
A few places where the existing audit procedures and the operational reality have come apart.
Access provisioning. The auditor wants to see the access list for production systems and reconcile it against named users with documented justification. Reasonable enough. The list now includes agent service accounts – one per agent role, often multiple – each of which has access to substantial portions of the system. The “named user” abstraction does not fit. The “documented justification” is buried in the agent’s specification, which the auditor has not been trained to read. The auditor signs off because the controls “exist,” but the operational reality is that the agent has broader access than any individual human, and that breadth is barely captured in the audit artifacts.
Change management. Standard SOC 2 change management procedures require that production changes be tracked, reviewed, and approved. The framework assumes that change volume is modest – dozens per week, perhaps – and that each change has a discernible author. An agent-heavy environment produces hundreds or thousands of changes per week. The author of each is the same agent service account. The reviewer is a human, but the human reviews a high-frequency stream of changes, and the audit artifact does not distinguish between a reviewer who read each change carefully and one who scrolled past most of them. The control says “changes are reviewed.” The control says nothing about whether the review was meaningful.
Logging and monitoring. The auditor expects logs that allow forensic reconstruction of actions. Logs exist. But the logs are now dominated by agent actions, and the agent actions are dominated by routine operations whose individual significance is low and whose aggregate behavior is the actual signal. A log that says “agent X read records A, B, and C” tells you almost nothing in isolation. The interesting questions – did the agent read more records than it should have, in what pattern, with what downstream effect – require the auditor to think about agent behavior at a population level. The audit procedures, designed for human-scale actions, do not naturally lead there.
Incident response. The runbooks SOC 2 expects assume incidents are triggered by named events with named responders. A material number of recent incidents in our experience have agent action somewhere in the causal chain – often as the proximate cause, sometimes as a contributing factor in a chain that includes both agent and human action. The runbooks did not anticipate this. The post-incident reviews are awkward; the “lessons learned” sections often read as if the agents were inanimate infrastructure rather than active participants in the incident. The audit procedure does not push back, because the procedure was not designed to.
Vendor management. SOC 2 vendor management procedures focus on third-party providers handling customer data. Foundation model providers handle a substantial volume of data passing through their inference APIs. They are vendors. They are in scope. The standard vendor management procedures – DPAs, SOC 2 reports from the vendor, evidence of encryption, evidence of access controls – mostly check out. What does not get audited is the structural question: how much of your business logic now lives inside a vendor’s model? That is a vendor concentration risk that the existing framework does not name, because the framework predates the concept.
What Compliant-On-Paper Looks Like
A typical company we work with passes their SOC 2 audit comfortably. The auditor finds no material weaknesses. The report is clean. The company displays the certification on their security page. The customers’ procurement teams check the box.
If you look at the actual operating environment, the controls are doing less work than the certification implies.
The agent service accounts have access to most of production. The access reviews are run quarterly, find the accounts present, confirm they are needed, and move on. The change review process produces signatures on agent-generated PRs at a rate of one per minute during peak hours, and the signatures are technically present. The logs capture every agent action and are retained for 90 days, which means the volume of logs has multiplied by ten in the last year, the query performance is now substantially worse, and most of the historically interesting questions you might ask in an incident review are no longer practical to answer at the necessary depth.
The certification has not changed. The underlying risk profile has. The auditor is auditing a system the framework was not designed to audit, with procedures that produce true findings for the questions they ask and silence on the questions they do not.
What Forward-Looking Compliance Looks Like
The companies that are taking this seriously are not waiting for AICPA guidance. They are running their own parallel compliance program, alongside the auditor’s procedures, that asks the questions the framework should be asking. A few patterns we have seen work.
Agent inventory as a first-class control. A continuously maintained registry of every agent operating in production, including its purpose, its data access, its decision authority, its escalation paths, and its named human owner. The registry is reviewed monthly. New agents go through a documented approval process before they go live. Agents that are no longer in use are decommissioned, not left running. This is not in the SOC 2 framework. It should be.
Agent action sampling for review. Beyond the standard high-volume logging, a sampled selection of agent actions – including the spec they were executing, the context they had, and the outcome they produced – is reviewed by a human on a rotation. The reviewer is checking not whether the action was authorized by the access controls (it was) but whether the action was the right action in the context. This is the kind of qualitative review the audit procedures do not currently require, and the kind that catches the failures the access controls miss.
Spec-level change control. Recognizing that the substantive change in an agent-heavy environment is the agent’s specification, not the individual implementation, the change control process is reframed around specifications. Spec changes are reviewed carefully. Implementation regenerations from approved specs require less ceremony. The audit artifact aligns with where the meaningful decisions are actually being made.
Concentration risk disclosure. A clear, named statement of the company’s dependencies on foundation model vendors, including what categories of business logic depend on those vendors, what the switching cost would be, and what mitigations are in place. This is not an audit requirement. It is the question the audit framework should be asking and is not.
Synthetic incident drills. Regular tabletop exercises that include scenarios where agent action contributes to or causes incidents. The drills surface the gaps in the existing incident response procedures. They produce updated runbooks. They train the team to think about agent behavior as part of the operational surface, not as inert infrastructure.
The Auditor Conversation
Most SOC 2 auditors are not antagonistic to this work. They are operating within procedures that have not yet been updated. Bringing the supplementary controls to the auditor’s attention and asking them to be considered in the audit produces, in most cases, a constructive conversation. The auditor may not be able to give you formal credit for controls that are not in the framework, but they will often acknowledge the controls in the audit report’s narrative sections, and the narrative is what the sophisticated customers actually read.
The conversations that go badly are the ones where the company has done none of this supplementary work and the auditor is the first one raising the questions. By that point, the audit is in motion, the gaps are visible, and the company has no good answer. Doing the work in advance turns the audit from an exposure into an exposition.
The Honest Statement
SOC 2 is a useful framework. It is also a partially outdated framework. The audit you pass today is auditing a system that operates differently than the system the framework was designed for. The certification still has value – to your customers, to your insurers, to your sales motion – but the operational risk it is supposed to indicate is no longer the full risk picture.
Do not rely on the certification as the totality of your compliance program. Build the supplementary program. Get ahead of the questions the framework will eventually ask. The companies that do this now will have a substantially easier time when the framework updates – and a substantially better operational posture in the meantime.
