With the Rise of AI Agents, SOC 2 Should Adapt or Risk Irrelevance

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?

• 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.

In access review procedures, a named human confirms that the reviewed account should still have access.  For agents, it’s common not to have a named owner. You need to piece that together after the fact, from circumstantial evidence and conjecture, by examining the agent's artifacts associated with humans, such as keys and repos.

At scale, agent ownership is an educated guess rather than a deterministic record. SOC 2 doesn’t account for this: a guessed owner and a recorded owner look the same in a review spreadsheet.

3. The name in the log pinpoints the actor.

This is the expensive one, which we already mentioned in our 10:03 am example. Often, agents work with borrowed credentials: a logged-in session, a dev token, or a service account. That’s the person who will appear in your logs and in your access review. This will pass the review, while absolutely ignoring the security differences between people and agents.

On the one hand, the access review will be completely accurate. On the other hand, it won’t tell you what you actually need to know. A recent study with Cloud Security Alliance found more than two-thirds of organizations cannot clearly distinguish AI agent actions from human ones.

4. What an account can do tells you what it’s expected to do.

Least privilege operates under the assumption that an account has a permanent job, and the list of things it can do tells us what it’s for. And for people, that’s usually correct. Unless your CEO wants to be an admin everywhere, access levels are tailored to the job.

For agents, the access limits the blast radius, but it doesn’t tell you what the agent is expected to do at any given moment. That depends on the instructions received, the context absorbed, and the decisions the agent makes. So, checking permissions gives you the widest possible view of what can happen without providing context for the agent’s actions. 

Three controls that pass without covering anything

Here’s how the assumptions we’ve mentioned reduce the effectiveness of three SOC 2 controls.

Nothing ever says an agent should stop (CC6.3)

Every SOC 2 audit tests offboarding, and for human employees, companies have gotten very good at it. HR systems, IdP, and SaaS systems work in tandem when the HR department flags a person for offboarding, thereby exercising its unquestionable authority. Even the evidence writes itself. 

There aren’t any HR systems for agents. There’s no centralized, agreed-upon body that’s in the position to say a specific agent should stop. It’s not a broken control, but one that just doesn’t encompass agents and the identities they use.

What makes it worse is that agents are mostly tied to humans, so when a person leaves, the agents set up in their name might keep running using OAuth grants or API keys, unless this scenario is accounted for.

Vendor review starts at purchase (CC9.2)

SOC 2 manages processes relating to vendor relationships. You contract, assess, collect a report, and review it annually; it works well for vendors who arrive on a purchase order. An MCP server is a vendor in every way that matters: it receives your data, acts on your behalf, and runs code nobody in the company reads.

Instead of a purchase order and a data agreement, it arrives in a config file. Often, there’s no company at the other end at all.

About three in ten names in our registry cannot be matched to an existing company. That’s a naming-space figure, not a specific environment, but it points to a fundamental compliance issue for many MCPs: you can’t receive a SOC 2 report from an unnamed vendor.

The same problem appears for AI agents. When we find them on employee machines, only some are safe to block; the rest are held back because the program's name can collide with something the customer built. Identifying an agent is harder than identifying a person. If you’re ready to explore the AI Agent Security controls, book a demo with Token Security to see what’s hiding in your environment.

Segregation of duties between two instances of the same policy (CC8.1)

When implementing change management, changes should be authorized, tested, approved, and implemented. In most implementations, the author and the approver must be different people due to segregation of duties.

When an agent makes a change and a second agent reviews it, the separation is only nominal, even though two identities were involved.

Meanwhile, the authorization moved beyond the scope of the audit. The decision about the change can happen in a prompt, in a tool that appears nowhere in the system description. The only evidence is a pull request.

The strongest argument against all of this

It’s worth noting that nothing in the Trust Services Criteria says “human”. CC6.2 uses “internal and external users,” whereas CC6.1 uses “protected information assets.” The criteria were written to avoid naming technologies and to describe results rather than methods. So there’s no reason not to cover agents.

You treat machine accounts as users, list agents in the system descriptions, and test them properly. It’s a thing that happens in the real world.

That said, given the current level of disruption, the ambiguity might not be enough. With no specific mentions of agents in the criteria, what gets covered is agreed between you and your auditor.

Both of you have a reason to prefer a scope that’s easy to evidence. As long as you can leave agents out without recording a single exception, some people will do it.

What a clean report has never meant

A clean report means your controls behaved the way you said they would, not that the description was complete. The gap used to be small enough to ignore, but it is no longer.

It is now entirely possible to hold an unqualified Type 2 report and be unable to answer, on the day it is issued, four questions about your own production environment.

Question	The control that covers it	Why it’ll pass
What is running in there?	User registration and authorization (CC6.2)	The agent was never registered, so nothing looked missing
Who authorized it?	Change authorization (CC8.1)	The decision happened in a prompt, upstream of the evidence
Whose credentials are they carrying?	Access review (CC6.1)	A real employee's credentials, with an approved role
Who could switch it off?	Access removal (CC6.3)	Offboarding ran correctly and never flagged agents

SOC 2 is not wrong. It is accurate about a world that moved. So treat machine accounts as users, and go further than the report asks. The permission list can tell you what an agent can reach; it does not tell you what an agent is there to do.

Closing this gap is what we mean by intent-based security: you establish what each agent is meant to do, then you make its access match. Identity is the layer where that control actually holds because it spans every system the agent touches.

The report will not change, but these controls are there for a reason, and attackers don’t care about checklists.

Every environment has an access review line that looks approved but says nothing. Token Security shows you the agent behind it: who owns it, whose credentials it uses, and whether what it can reach still aligns with what it's there to do.

Book a demo and we'll walk your environment together.

Sponsored and written by Token Security.