"Some compliance is mostly for show, and that’s being charitable," writes Token Security — and with AI agents proliferating across enterprise systems, the firm argues, SOC 2 risks becoming precisely that: a certificate that proves controls behaved as described while missing how those controls actually operate in a changed environment.
How AI agents break SOC 2's assumptions
Token Security lays out a simple, concrete example: a production database at 10:03 a.m. shows 50 queries under the name of a senior engineer. An access review spreadsheet looks correct; all controls appear to have been exercised. But the engineer was getting coffee — their AI agent was pushing updates to production. That divergence exposes four assumptions that the Trust Services Criteria no longer reliably support.
- Someone approves an account before it’s spawned. For humans that approval path is visible; agents can be created as side effects (an OAuth “Allow” click, an API key pasted into a config, an MCP server entered in JSON).
- Every account has a known owner. Agents frequently lack a named owner; ownership must be inferred from keys, repos, or other artifacts.
- The name in the log pinpoints the actor. Agents often operate using borrowed credentials, so logs show the human or service account, not the agent making autonomous decisions.
- What an account can do tells you what it’s expected to do. Agents’ behavior depends on instructions, context, and decision-making — permission lists do not capture intent.
Which SOC 2 controls can pass while covering nothing
Token Security identifies three trust-service controls that can be hollowed out by agent activity.
- Offboarding (CC6.3). Organizations have mature HR-driven offboarding for people, but there are no HR systems for agents. Agents tied to departed employees may keep running on OAuth grants or API keys unless accounted for.
- Vendor review (CC9.2). The framework assumes vendor relationships start with purchase and contractual review. An MCP server — which "receives your data, acts on your behalf, and runs code nobody in the company reads" — can arrive in a config file with no purchase order or data agreement. Token Security reports that about three in ten names in its registry cannot be matched to an existing company, creating a compliance blind spot for unnamed MCPs and agents.
- Segregation of duties (CC8.1). Change management depends on separation between author and approver. When an agent makes a change and a second agent reviews it, the separation is nominal. Authorization can happen in a prompt or tool outside the system description, leaving the only evidence as a pull request.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleWhy the Trust Services Criteria can technically cover agents — and why they often do not
Token Security notes the Trust Services Criteria avoid the word "human" and emphasize results over methods: CC6.2 uses "internal and external users," and CC6.1 refers to "protected information assets." That means, in principle, machine accounts can be treated as users, listed in system descriptions, and tested.
In practice, however, scope is negotiated between the audited organization and the auditor. Both parties have incentives to favor evidence that is easy to produce. As a result, the firm warns, agents can be left out of scope without triggering recorded exceptions — producing a clean Type 2 report that nonetheless leaves operators unable to answer four core questions about their production environment on the day the report is issued.
What this means for technologists, procurement teams, and auditors
- Technologists and security teams should expect access reviews and offboarding procedures to miss agents unless machine accounts are explicitly treated as users and ownership is recorded. Token Security recommends making identity the layer where intent-based controls operate.
- Procurement teams who demand SOC 2 reports should recognise that a delivered report confirms controls behaved as described, not that the description captured agent-driven activity. Vendors or MCPs that appear only in configuration files may evade traditional vendor review steps.
- Auditors need to decide whether to require that organizations list and test machine accounts. Token Security warns that absent explicit treatment of agents, audits will continue to pass controls that provide incomplete assurance.
Practical direction: define intent and treat machine accounts as users
Token Security’s prescription is direct: treat machine accounts as users, record agent ownership, and move toward intent-based security — establish what each agent is meant to do, then align its access to that purpose. "Identity is the layer where that control actually holds because it spans every system the agent touches," the firm writes.
The article also frames a commercial offering around this gap: Token Security says its tooling "finds every agent, assigns an identity, and remediates its access to the job it was made to do," and invites readers to book a demo to see "what's hiding in your environment." Whether organizations adopt that or other approaches, the practical challenge is clear: without explicit treatment of agents in system descriptions, SOC 2 reports will continue to validate a shifted world using a rulebook written for a different set of actors.
Read the original Token Security article on BleepingComputer
