SOC 2 Was Built for Humans, and Agents Don't Play by Those Rules
A contributed analysis published on BleepingComputer, authored by identity-security vendor Token Security, argues that SOC 2 — the compliance framework underpinning most enterprise vendor trust relationships — is quietly failing to do its job as AI agents take on more production access. The core problem isn't that SOC 2's Trust Services Criteria are wrong; it's that they were written for a world where every credential mapped to exactly one accountable human. AI agents break that assumption by operating through human credentials — OAuth grants, API keys, service accounts — while making autonomous decisions no auditor's checklist was designed to see.
The piece frames this as an audit-scope problem, not a theoretical one: agents can pass every existing SOC 2 control on paper while the actual actor behind a given action remains invisible to the audit trail.
Details
| Attribute | Value |
|---|---|
| Publisher | BleepingComputer (contributed analysis) |
| Author / Vendor | Token Security (identity security) |
| Published | September 25, 2026 |
| Framework affected | SOC 2 Trust Services Criteria |
| Core issue | Agent activity is indistinguishable from human activity under current controls |
| Key supporting stat | Cloud Security Alliance study: more than two-thirds of organizations cannot clearly distinguish AI agent actions from human ones |
| Proposed fix | "Intent-based security" — treat machine accounts as formal users with distinct identities |
| Category | Compliance / Identity Security |
The Four Assumptions SOC 2 Controls Quietly Depend On
Token Security's analysis walks through specific Trust Services Criteria (TSC) and shows how each one leans on an assumption that no longer holds once an agent is in the loop.
Account Approval (CC6.1)
SOC 2 expects new accounts to go through a registration or approval process. Agents don't arrive that way — they spawn from an OAuth click, an API key pasted into a config file, or a connector added to a workflow tool. There is often no discrete "account creation" event for an auditor to sample.
Known Ownership (CC6.2)
Controls assume every account has a named human owner. Agent ownership, by contrast, frequently has to be reconstructed after the fact from circumstantial evidence — which team deployed it, whose API key it was configured with, which ticket referenced it — rather than read directly off a record.
Log Attribution (CC6.1)
This is the sharpest gap. Because agents typically operate using borrowed credentials, activity logs show the human whose session or token the agent used, not the agent itself. The audit trail records the wrong actor by design. Token Security cites a Cloud Security Alliance study finding that more than two-thirds of organizations cannot clearly distinguish AI agent actions from human ones in their own logs.
Permission-Based Intent (CC8.1)
Access reviews are built around the question "what can this account reach?" That tells an auditor the ceiling of what's possible, but not what the account actually did or why — and an agent's behavior depends on the instructions it received and the context it absorbed, not just the permissions it was granted.
Three More Controls the Analysis Calls "Hollowed Out"
Beyond the four TSC failures above, the piece identifies three additional controls that technically still function but no longer provide meaningful assurance:
- Offboarding (CC6.3) — There is no centralized authority responsible for removing an agent when it should be retired. Agents tied to a departing employee can persist indefinitely through leftover OAuth grants or API keys that nobody remembers to revoke.
- Vendor Assessment (CC9.2) — Model Context Protocol (MCP) servers and third-party agent connectors get added via config files, with no purchase order and often no formal vendor review. Token Security notes that roughly three in ten names appearing in its own agent registry cannot be matched to an existing company — meaning a SOC 2 report can't even be requested from a vendor that can't be identified.
- Segregation of Duties (CC8.1) — A workflow where one agent "reviews" another agent's change looks like segregation of duties on paper, but the actual authorization decision happens inside a prompt or a model's reasoning step — outside the scope of anything an audit can currently inspect.
A Realistic Scenario: The Audit Trail That Lies
The analysis illustrates the problem with a scenario rather than a confirmed breach: database activity logged at 10:03 AM under a senior engineer's credentials shows roughly 50 queries, gets waved through a routine access review, and appears completely unremarkable — except the engineer was unavailable at the time. An agent acting on their behalf, using their borrowed session, was actually the one executing changes against production. Nothing in the standard SOC 2 evidence set would have caught the discrepancy, because the log, the credential, and the review all pointed to the human of record.
This is presented as illustrative of a structural gap rather than a documented incident, but it maps directly onto the four TSC failures above: approval, ownership, attribution, and intent all assumed a human was the one acting.
Token Security's Proposed Fix: Intent-Based Security
Rather than proposing new checkboxes bolted onto existing controls, Token Security argues for a different control philosophy: intent-based security. The recommendation has two parts:
- Treat machine accounts as formal users. Every agent should be assigned its own distinct identity — not a shared service account, not a borrowed human token — that spans every system it touches, so its actions are attributable to it specifically rather than to whoever's credentials it happened to be using.
- Establish what each agent is supposed to do, then align its access to that purpose. A permission list shows what an agent can reach; it says nothing about what it's there to do. Closing that gap means defining intended function per agent and treating deviation from that function — not just excess permission — as the signal worth auditing.
The company frames this as an extension of SOC 2's underlying goals rather than a replacement: the framework isn't wrong about the world it was built for, it just hasn't caught up to a world where non-human identities take autonomous action inside the systems it's supposed to govern.
Impact Assessment
| Impact Area | Description |
|---|---|
| Audit Assurance | SOC 2 reports may certify controls that don't actually cover agent-driven activity, giving customers false confidence |
| Vendor Risk Management | Unidentifiable MCP/agent vendors make standard third-party risk assessment (SOC 2 report requests) structurally impossible |
| Incident Attribution | Borrowed-credential logging delays or defeats root-cause analysis when an agent, not a human, causes an incident |
| Access Governance | Permission-based reviews miss intent drift — an agent operating within its granted scope but outside its intended purpose |
| Offboarding Hygiene | Orphaned agent credentials tied to former employees can persist as standing access long after departure |
| Regulatory Exposure | Organizations relying on SOC 2 attestations for regulated data may be understating actual non-human-identity risk |
Recommendations
For Compliance Teams
- Do not treat a clean SOC 2 report as proof that AI agent activity is covered — ask auditors directly how agent-driven access was sampled and attributed.
- Push for agent inventories as a discrete audit artifact, separate from the standard human user-access list.
- Require named ownership for every agent and machine identity before the next audit cycle, not after a gap is found.
For Security Teams
- Stop provisioning agents against shared or borrowed human credentials; issue distinct, traceable identities per agent across every system it touches.
- Instrument logging to capture the actual acting agent, not just the session token it rode in on.
- Build an intent baseline per agent (what it's supposed to do) so that deviation — not just excess permission — becomes a detectable signal.
- Extend offboarding checklists to explicitly include agent and API-key cleanup tied to departing employees or retired workflows.
For Vendor/Third-Party Risk Managers
- Flag any MCP server, connector, or agent integration whose publisher cannot be matched to a verifiable company — it cannot be meaningfully assessed for SOC 2 or any other compliance standard.
- Treat agent-based integrations added via config file the same as any other vendor relationship requiring a review, not as a no-cost technical convenience.
Key Takeaways
- SOC 2's Trust Services Criteria assume every credentialed action maps to one accountable human — an assumption AI agents routinely break by acting through borrowed credentials.
- Four specific controls — account approval (CC6.1), known ownership (CC6.2), log attribution (CC6.1), and permission-based intent (CC8.1) — fail to distinguish agent activity from human activity.
- Three more controls — offboarding (CC6.3), vendor assessment (CC9.2), and segregation of duties (CC8.1) — still technically function but provide materially weaker assurance once agents are involved.
- A Cloud Security Alliance study cited in the analysis found more than two-thirds of organizations cannot clearly distinguish AI agent actions from human ones in their own environments.
- Token Security recommends "intent-based security": issuing agents distinct, traceable identities and aligning access to a defined purpose, rather than relying on permission scope alone.
- Roughly three in ten names in Token Security's own agent/MCP registry could not be matched to a real company — underscoring that vendor identification, not just access control, is now a compliance gap.