Some compliance is mostly for show, and that’s being charitable. You go through it for the website badge, not to find weak spots in your organization. SOC 2 is not like that.
There’s a reason your customers’ procurement teams demand it. They want to know whether they can trust you with their data, and SOC 2 compliance is the accepted way to demonstrate that. It might not be the reason a deal closes, but that deal wouldn’t have closed without it.
We’ve lived “move fast and break things” for so long that we assume disruption must mean breaking stuff by definition. Only when it comes to AI agents, it’s not so easy because of the way they use the existing infrastructure.
Consider an access review row. A production database, 10:03 am, 50 queries under the name of a senior engineer. You were right to approve it; everything conforms accurately to the control. Only that engineer was getting coffee at the time, while their agent was pushing updates to production.
SOC 2’s technology-neutral criteria can cover AI agents, but they do not explicitly require organizations or auditors to treat agents as a distinct identity class. That discretion allows AI agents to add risk to an environment without failing a single control.
If SOC 2 lets you get away with this, the framework either needs to change or risk becoming outdated.
What’s Happening
During an audit, you’re tested on two things: whether the control meets a compliance criterion, and whether it operated throughout the review period. But what about testing whether the design is still relevant?
Sometimes, when there’s a shift, a test gets harder. But often, it just gets emptier, because the activity happens elsewhere, which brings us to the Trust Services Criteria in SOC 2. It’s not that they’re wrong, but four of the common assumptions no longer hold, and as a result, three controls are hollowing out.
The assumptions are:
- Someone approves an account before it’s spawned.
- Every account has a known owner.
- The name in the log pinpoints the actor.
- What an account can do tells you what it’s expected to do.
Four assumptions that no longer hold (CC6.1–CC6.3)
Every access criterion is based on assumptions about what it controls. And as long as the actors were human, those assumptions were safe enough that nobody needed to write them. With agents, this is no longer the case.
1. Someone approves an account before it’s spawned.
SOC 2 requires you to register and approve a user before granting login capabilities. For humans, that means someone asking for a login, with someone else approving and logging it. Agents, on the other hand, are akin to a side effect of an overarching action.
It can be a developer clicking “Allow” on an OAuth screen, an API key that’s pasted into a config file, or an MCP server added to a JSON file. No one was asked to approve the creation of an agent; it just happened.
2. Every account has a known owner.