Many compliance frameworks exist primarily for appearance, serving mainly to provide a badge for marketing purposes. SOC 2 operates differently. Procurement teams across organizations demand it because it represents a verifiable commitment to protecting customer data. Without it, deals often fail to close regardless of other factors.

The technology industry has embraced "move fast and break things" for years, assuming disruption inherently involves breaking existing systems. AI agents present a different challenge: they operate within existing infrastructure in ways that circumvent traditional controls. Consider a production database access review showing 50 queries from a senior engineer at 10:03 am. The access appears legitimate and passes every control, yet the engineer was away from their desk while their agent executed those queries. SOC 2's technology-neutral criteria could theoretically cover agents, but they do not explicitly require organizations or auditors to treat agents as a distinct identity class, allowing them to introduce risk without triggering any control failures.

If SOC 2 permits this oversight, the framework must either evolve or face obsolescence.

What's Happening

Audits typically verify two things: whether controls meet compliance criteria and whether they functioned throughout the review period. Testing whether the design remains relevant is rarely included. When significant shifts occur, tests often become hollow as activities migrate elsewhere. Four foundational assumptions underlying the Trust Services Criteria in SOC 2 no longer universally apply, causing three controls to lose their effectiveness.

Four assumptions that no longer hold (CC6.1–CC6.3)

Every access control criterion rests on assumptions about what it governs. When actors were exclusively human, these assumptions were sufficiently reliable that they remained unwritten. Agents have changed this equation.

  1. Someone approves an account before it's spawned. SOC 2 mandates user registration and approval before granting access credentials. For humans, this involves a request and documented approval. Agents function as byproducts of broader actions—a developer clicking "Allow" on an OAuth prompt, an API key inserted into a configuration file, or an MCP server added to JSON. No explicit approval request occurs; the agent simply comes into existence.
  2. Every account has a known owner. Access review procedures require a named human to confirm that an account should retain its access. Agents frequently lack a named owner. Determining ownership requires reconstructing details from circumstantial evidence and inference, examining artifacts like keys and repositories. At scale, agent ownership becomes an educated guess rather than a documented fact. SOC 2 reviews cannot distinguish between guessed and recorded owners.
  3. The name in the log pinpoints the actor. This represents the most consequential assumption. Agents typically operate using borrowed credentials—active sessions, developer tokens, or service accounts. The logs and access reviews will show the person whose credentials were borrowed. The review passes while obscuring critical security differences between human and agent actions. A Cloud Security Alliance study found that 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 assumes an account has a permanent role and its permissions indicate its purpose. For people, this generally holds true. For agents, permissions define the blast radius but reveal nothing about what the agent is supposed to accomplish at any moment. That depends on received instructions, absorbed context, and the agent's own decisions. Permission checks provide the broadest possible view of potential actions without offering context for the agent's actual purpose.

Three controls that pass without covering anything

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

SOC 2 audits routinely test offboarding procedures, and organizations have refined this process for human employees. HR systems, identity providers, and SaaS platforms coordinate when HR initiates offboarding, exercising clear authority. Documentation flows naturally. No equivalent exists for agents. No centralized body possesses the authority to declare that a specific agent should cease operation. The control itself is not broken; it simply does not address agents and their associated identities. The situation worsens because agents typically tie to humans. When a person departs, agents created under their name may continue running through OAuth grants or API keys unless this scenario receives explicit attention.

Vendor review starts at purchase (CC9.2)

SOC 2 governs vendor relationship processes: contracting, assessment, report collection, and annual review. This works well for vendors arriving via purchase order. An MCP server functions as a vendor in every meaningful way—it receives data, acts on behalf of the organization, and executes code that no one in the company has reviewed. Instead of a purchase order and data agreement, it arrives in a configuration file. Often no company exists behind it at all. Approximately three in ten names in registries cannot be matched to an existing company. This represents a naming-space observation rather than environment-specific data, but it signals a fundamental compliance problem: you cannot obtain a SOC 2 report from an unnamed vendor. The same issue affects AI agents. When discovered on employee machines, some can be safely blocked, while others remain because the program name might collide with something the customer created. Identifying an agent proves harder than identifying a person.

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

Change management requires that changes be authorized, tested, approved, and implemented. Most implementations enforce segregation of duties, requiring the author and approver to be different people. When one agent makes a change and a second agent reviews it, the separation exists only nominally despite involving two identities. The authorization decision itself moves beyond audit scope. The choice about the change may occur in a prompt or a tool absent from the system description. The only evidence is a pull request.

The strongest argument against all of this

The Trust Services Criteria contain no requirement that actors be human. CC6.2 refers to "internal and external users," while CC6.1 addresses "protected information assets." The criteria were intentionally written to avoid naming specific technologies and to describe outcomes rather than methods. Nothing prevents them from covering agents. Organizations can treat machine accounts as users, list agents in system descriptions, and test them appropriately. This happens in real-world implementations. However, given the current scale of disruption, this ambiguity may prove insufficient. Without explicit agent mentions in the criteria, auditors and organizations negotiate what falls within scope. Both parties have incentives to prefer scopes that generate clear evidence. As long as agents can be excluded without recording exceptions, some will exclude them.

What a clean report has never meant

A clean report confirms that controls operated as described, not that the description was complete. This gap was previously small enough to overlook. It no longer is. An organization can hold an unqualified Type 2 report and be unable to answer four fundamental questions about its own production environment on the day the report is issued:

  • What is running in there? User registration and authorization (CC6.2) — The agent was never registered, so nothing looked missing
  • Who authorized it? — The decision happened in a prompt, upstream of the evidence
  • Whose credentials are they carrying? — A real employee's credentials, with an approved role
  • Who could switch it off? — Offboarding ran correctly and never flagged agents

SOC 2 is not flawed. It accurately describes a world that has moved on. Organizations should treat machine accounts as users and extend controls beyond what the report requires. Permission lists reveal what an agent can access but not what it exists to accomplish. Closing this gap requires intent-based security: establishing what each agent is designed to do, then ensuring its access aligns with that purpose. Identity becomes the control layer where this actually holds, spanning every system the agent touches. The report itself will not change, but these controls exist for a reason, and attackers ignore checklists.

Every environment contains an access review line that appears approved but reveals nothing. Organizations need visibility into the agent behind it: who owns it, whose credentials it uses, and whether what it can reach still matches what it is there to do.