Defender Impact
The emergence of AI agents operating under human credentials has quietly invalidated four foundational assumptions in SOC 2’s Trust Services Criteria — and this analysis is the clearest articulation yet of exactly which controls are hollowing out and why. For compliance-conscious security teams, it provides a concrete audit gap to close rather than a vague concern to park.
Capability Overview
Token Security’s analysis targets the structural mismatch between SOC 2’s technology-neutral design and the operational reality of AI agents acting autonomously within enterprise environments. The framework’s Trust Services Criteria — specifically CC6.1 through CC6.3, which govern logical and physical access — were built on four assumptions: that a human approves every account before it is created; that every account has a known, accountable owner; that the identity in a log entry identifies the actual actor; and that an account’s permissions reflect its expected behaviour.
All four break down under agentic AI. An agent can be spawned dynamically without a formal provisioning workflow, operate under a named engineer’s credentials, produce log entries indistinguishable from human activity, and acquire access scopes that were never designed with agent behaviour in mind. The article illustrates this with a production database scenario: 50 queries logged under a senior engineer’s identity at 10:03 AM while the engineer was away from their desk. Every control passes. No alarm fires. The audit evidence looks clean.
The core argument is not that SOC 2 is wrong, but that its technology-neutral stance — historically a strength — now creates a blind spot wide enough for agentic systems to operate invisibly through an entire audit period. The framework either needs explicit agent-identity criteria, or organisations must voluntarily extend their control design to compensate.
Defensive Advances
This analysis gives defenders three concrete advances they did not have before in a single structured argument:
Named control exposure. By pinpointing CC6.1–CC6.3 as the specific hollowing-out controls, security teams can immediately scope a gap assessment without starting from first principles. This is actionable in existing audit programmes.
Broken-assumption checklist. The four enumerated assumptions serve as a ready-made test harness. Teams can walk each assumption against their current agent inventory and determine whether their audit evidence would survive agent-aware scrutiny.
Compliance leverage. Framing the problem in SOC 2 language gives security teams a procurement and contractual lever. Customers demanding SOC 2 attestation can now reasonably ask whether the scope covers agent identities — creating market pressure for faster framework evolution.
Residual Gaps
The analysis is a strong conceptual advance, but several maturity questions remain before its recommendations translate into consistent defensive practice.
Auditor consensus is absent. SOC 2’s technology-neutral criteria mean that whether an auditor treats agents as a distinct identity class is currently discretionary. Until the AICPA issues explicit guidance or a critical mass of auditors adopts agent-aware testing, the gap described in this article will persist even for organisations that want to close it.
NHI tooling maturity varies widely. Treating agents as a distinct identity class in IAM systems requires non-human identity (NHI) management capabilities that many organisations are still acquiring. The compliance argument is ahead of the tooling baseline for a significant proportion of the market.
Scope boundary decisions are unresolved. Should an agent spawned ephemerally for a single task be in scope for access review? Should long-running agents with persistent credentials be treated as service accounts? These definitional questions must be answered at the organisational level before controls can be meaningfully designed.
Framework Mapping
The gaps surfaced here map directly to AML.T0012 (Valid Accounts) — agents operating under legitimate human credentials represent exactly the valid-account abuse ATLAS identifies. AML.T0103 (Deploy AI Agent) and AML.T0083 (Credentials from AI Agent Configuration) capture the provisioning and credential inheritance risk. On the OWASP side, LLM08 (Excessive Agency) and LLM07 (Insecure Plugin Design) reflect the structural problem of agents accumulating access beyond what their intended function requires.
Deployment Considerations
Organisations should treat this as a compliance gap assessment trigger, not a framework replacement exercise. The sequencing priority is: (1) inventory all AI agents operating in production and map their credential sources; (2) determine whether existing IAM systems can tag and surface agent accounts separately; (3) engage your SOC 2 auditor proactively to determine their current stance on agent identity scope. Do not wait for framework updates — voluntary control extensions are both feasible and defensible under the existing technology-neutral criteria.
Defender Checklist
- Run an agent inventory against your current SOC 2 control scope and identify gaps in CC6.1–CC6.3 coverage
- Implement NHI tagging in IAM so access reviews distinguish agent accounts from human accounts
- Document agent provisioning, ownership assignment, and deprovisioning workflows
- Engage your SOC 2 auditor to confirm whether agent-initiated actions are in scope for the next audit period
- Add agent identity criteria to vendor due diligence questionnaires for third-party SaaS tools deploying agents in your environment
- Review log pipelines to determine whether agent actions are attributable separately from the human accounts they operate under