Skip to content
SecAIQ

AI Agents Are Straining SOC 2 Assumptions About Identity and Access

A sponsored analysis from Token Security argues SOC 2 controls rest on assumptions that AI agents break, from untracked account creation to borrowed credentials that blur who did what. Here is what it means for organizations.

Written by Safa PAKSU· Published Sep 26, 2026 ·4 min read

Compliance built for humans meets autonomous software

SOC 2 is one of the most widely used frameworks for showing customers that a company handles security responsibly. Its controls were written with a familiar picture in mind: people who are hired, given accounts, reviewed periodically and removed when they leave. A recent analysis published on BleepingComputer argues that AI agents are quietly undermining that picture, and that the framework needs to adapt or lose its usefulness. Note that the piece is sponsored content from identity-security vendor Token Security, so it reflects that company's perspective.

The central claim is not that SOC 2 controls are badly designed. Rather, the assumptions underneath them no longer hold once autonomous agents work inside company systems, often using credentials that belong to a human.

Four assumptions that stop holding

  • Accounts are approved before they exist. Agents can appear through OAuth grants, configuration files or API keys, without anyone formally approving a new account.
  • Every account has a known owner. The article says ownership of an agent tends to be an educated guess rather than a deterministic record.
  • Logs show who acted. When an agent works through borrowed human credentials, activity is recorded under the person's name, masking what the agent actually did.
  • Permissions reflect intent. Knowing what an agent is allowed to access says little about what it was designed to do.

Controls that risk becoming hollow

The analysis points to three SOC 2 criteria as examples of controls that may still be ticked off on paper while losing their meaning:

  • CC6.3 (removing access): Offboarding processes are built around employees. Agents may have no equivalent step, so they can keep running after the person who set them up has left.
  • CC9.2 (vendor review): Agents often connect to outside tools through MCP servers. The article says roughly 30% of these servers cannot be matched to an existing company, which makes traditional vendor due diligence hard to apply.
  • CC8.1 (segregation of duties): If several agents review one another's work, the separation may be nominal rather than real, because the same underlying access and ownership can sit behind them all.

A visibility problem, not just a paperwork problem

The article cites a Cloud Security↗ Alliance study finding that more than two-thirds of organizations cannot clearly tell AI agent actions apart from human ones. That matters well beyond audits. If an incident occurs, investigators need to know whether a person or an automated process made a change, and an audit trail that cannot answer that question weakens both accountability and response.

What the author recommends

The suggested direction is to treat machine and agent accounts as registered identities in their own right, with explicit records of who owns them and why they exist. It also calls for intent-based controls, meaning access is aligned to an agent's actual purpose, rather than relying only on periodic reviews of permission lists.

What readers can do

Whatever one thinks of any single vendor's framing, the underlying practices are sensible for any organization adopting AI agents:

  • Keep an inventory of agents, integrations and the tokens or keys they use, including ones employees set up themselves.
  • Assign a named owner to each agent and record its intended purpose.
  • Avoid sharing human credentials with agents where possible; give them separate identities so logs are meaningful.
  • Grant least privilege and set expiry dates on agent access.
  • Include agents in offboarding so that revoking a person's access also reviews what they created.
  • Vet external tools such as MCP servers before connecting them, and be cautious with ones whose publisher is unclear.
  • Ask vendors how they separate agent activity from human activity in their own logs and audit reports.

Why it matters

Compliance reports are often used as shorthand for trust. If the frameworks behind them do not account for how AI agents actually behave, a clean report may give a less complete assurance than readers assume. Standards bodies and auditors will likely need to address agent identities more explicitly; in the meantime, organizations can close much of the gap themselves through better inventory, ownership and logging.

Source: BleepingComputer

#SOC 2 #AI agents #identity security #compliance #access control #non-human identities #MCP
View as Markdown

Was this helpful?

Share on