Why SOC 2 Compliance May Miss Hidden AI Agent Security Risks

Some compliance programs are treated as a formality—a badge for a website rather than a way to uncover weaknesses. SOC 2 is not intended to work that way.

There is a reason customer procurement teams require SOC 2 reports: they want confidence that their data is protected. SOC 2 compliance may not be the only reason a deal closes, but without it, many deals would not move forward.

However, the rise of AI agents is challenging assumptions that have shaped access management, identity security and compliance audits for years. Organizations have spent so long “moving fast and breaking things” that they often assume destruction must involve something visibly breaking. With AI agents, the problem is less obvious.

AI agents can use existing infrastructure, borrowed credentials and permissions that were originally granted to human users. Learn how AI agents use existing infrastructure.

Consider an access review entry: an operational database, 10:03 a.m., and 50 queries associated with a senior engineer. Approving the access appears reasonable. All the evidence fits the control. Yet at that moment, the engineer may have been having coffee while an AI agent used the engineer’s credentials to push updates to production.

SOC 2’s technology-neutral standards can cover AI agents, but they do not explicitly require organizations or auditors to treat agents as a separate identity class. That discretion can allow AI agents to introduce significant risks without causing a control failure.

If organizations can satisfy SOC 2 while missing these risks, the framework may need to evolve—or risk becoming less relevant to modern environments.

Why AI agents create a SOC 2 visibility gap

An audit tests whether controls meet compliance standards and whether those controls operated throughout the review period. But it does not necessarily test whether the control design remains appropriate as technology and operating models change.

That distinction matters for AI agents. Some agent activity can be difficult to test because it occurs through existing identities, configuration files, developer tools or other infrastructure outside the traditional review process.

The Trust Services Criteria for SOC 2 are not inherently wrong. However, four assumptions that commonly support access controls no longer reliably apply to AI agents:

• Someone approves an account before it is created.
• Every account has a known owner.
• The identity in the log represents the actor responsible for the activity.
• An account’s permissions reveal what it is expected to do.

Four AI agent identity assumptions that no longer hold

Many access controls are based on assumptions about what is being controlled. When the actors are human, those assumptions are often reliable enough to remain implicit. AI agents make them far less dependable.

1. Someone approves the account before it is created

SOC 2 requires users to be registered and authorized before they can log in. For human users, this usually means that one person requests access, another approves it, and the decision is recorded.

AI agents can be created as side effects of other actions. A developer may click “Allow” on an OAuth screen, paste an API key into a configuration file, or add an MCP server to a JSON file. No one may explicitly approve the creation of the agent. It simply begins operating.

2. Every account has a known owner

During an access review, a designated person verifies that an account should continue to have access. AI agents, however, often have no formally designated owner.

Ownership may have to be reconstructed after the fact by examining related keys, repositories and other human-associated artifacts. At scale, agent ownership can become an educated guess rather than a definitive record.

SOC 2 does not necessarily distinguish between an inferred owner and a recorded owner. In both cases, the information may appear identical in the review spreadsheet.

3. The identity in the log represents the actual actor

AI agents frequently operate with borrowed credentials, including login sessions, development tokens and service accounts. Those credentials—not the agent—are what appear in logs and access reviews.

The resulting access review may be technically accurate while failing to explain the security-relevant difference between a human employee and an AI agent using that employee’s permissions.

A recent Cloud Security Alliance report found that more than two-thirds of organizations cannot clearly distinguish AI agent behavior from human behavior.

4. Permissions reveal what an account is expected to do

Least privilege is based on the idea that an account has a persistent job and that its permissions indicate its purpose. For human users, access levels are generally tailored to a role.

For an AI agent, permissions can limit the potential blast radius without explaining what the agent is supposed to do at a particular moment. Its actions may depend on instructions, absorbed context and decisions made during execution.

As a result, reviewing permissions provides a broad picture of what an agent could do, but not the context needed to determine whether a specific action was appropriate.

Three SOC 2 controls that AI agents can bypass

The assumptions above can reduce the effectiveness of several SOC 2 controls, even when the controls appear to be operating correctly.

Agents may continue running after offboarding (CC6.3)

Every SOC 2 audit tests offboarding. For human employees, companies typically rely on HR systems, identity providers and SaaS systems to remove access when a person leaves.

AI agents do not have an equivalent personnel system. There may be no central authority responsible for deciding that a particular agent should be terminated. The control may not be broken, but it may fail to contain an agent and the identity it uses.

Agents are also frequently associated with individual employees. If an employee leaves, an agent configured in that person’s name may continue to operate through OAuth permissions or API keys unless the organization has specifically accounted for that possibility.

Vendor reviews may not cover AI tools and MCP servers (CC9.2)

SOC 2 addresses processes related to vendor relationships. Organizations typically evaluate a vendor, collect its reports and review the relationship periodically. This process works well for vendors that receive purchase orders and have identifiable corporate entities.

However, an MCP server can receive user data, act on a user’s behalf and execute code that no one in the company has reviewed. Instead of arriving through a purchase order or data contract, it may be introduced through a configuration file. In some cases, there may be no identifiable company on the other side.

Three out of 10 names in Token Security’s registry did not match an existing company. This is a namespace figure and does not represent a specific environment, but it illustrates a fundamental compliance issue for some MCP servers: organizations cannot receive SOC 2 reports from unnamed vendors.

A similar problem affects AI agents found on employee machines. Some can be safely blocked, while others may conflict with software built by the customer. Identifying agents can be more difficult than identifying individual users.

Ready to explore security controls for AI agents? Book a Token Security demo to see what may be hidden in your environment.

Two AI agents do not necessarily provide separation of duties (CC8.1)

Under change management controls, changes must be approved, tested and implemented. In many environments, the person who authors a change must be different from the person who approves it.

If one AI agent makes a change and another AI agent reviews it, the separation may be only nominal—even when two different identities are involved.

Decisions about changes may also be made through tool prompts that do not appear in the system description. The only visible evidence may be the pull request, leaving the underlying decision process outside the audit trail.

The strongest objection: SOC 2 does not say “human”

The Trust Services Criteria do not explicitly say that the relevant users must be human. CC6.2 refers to internal and external users, while CC6.1 refers to protected information assets. The standards were designed to avoid naming specific technologies and to focus on outcomes rather than implementation methods.

That means organizations can treat machine accounts as users, list AI agents in the system description and test them appropriately. Some organizations already do this.

However, the current ambiguity leaves important decisions to the organization and its auditor. Both parties may have incentives to focus on areas where evidence is easy to collect. In some cases, agents can be excluded without a documented exception.

Why a clean SOC 2 report may not tell the whole story

A clean SOC 2 report means that the controls operated as specified. It does not necessarily mean that the system description was complete or that every important identity was visible to the controls.

The gap may now be large enough for an organization to receive a clean Type 2 report while still being unable to answer four basic questions about its production environment:

How organizations can close the AI agent identity gap

SOC 2 is not a mistake. It accurately describes the controls and evidence included in the audit. The problem is that organizations may be applying those controls to a world that has changed.

Organizations should treat machine accounts as users and go beyond what is required in the report. A permission list shows what an AI agent can access; it does not explain what the agent is intended to do.

Bridging that gap is the purpose of intent-based security: establish what each agent is supposed to do and compare its access with that purpose. Identity is the layer where this control can be applied across the systems that agents interact with.

The report may not change, but the controls exist for a reason—and attackers do not care about checklists.

Every environment has access review entries that appear approved but leave important questions unanswered. Token Security identifies the agent behind the activity, its owner, the credentials it uses and whether its access is consistent with its purpose.

Book a demo to review your environment.

Sponsored and written by Token Security.