Security1 publisher2 min readPublished
SOC 2 access reviews credit humans with actions their AI agents took
SOC 2 controls CC6.1 to CC6.3 let AI agents act under human credentials without failing a check, a BleepingComputer column argues. A clean review can leave responders unable to say who ran a query, and the criteria already let firms register agents as their own identity.
The Watch · Security desk
What happened
- A BleepingComputer column argues SOC 2's technology-neutral criteria can cover AI agents but do not require companies or auditors to treat them as a distinct identity class.
- Its example is an access-review row showing 50 production database queries at 10:03 am under a senior engineer's name, run by the engineer's agent while the engineer was getting coffee.
- Agents often run on borrowed credentials, such as a logged-in session, a dev token or a service account, so the human's name appears in the logs and in the access review.
- A study the column says was run with the Cloud Security Alliance found more than two-thirds of organizations cannot clearly distinguish AI agent actions from human ones.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- constraint Incident responders working from these logs cannot attribute a production change to the engineer or to the agent without separate evidence.
- decision Because the criteria already cover agents, a company can register them as a separate identity class, with an approver, an owner and their own credential, and have that tested now.
- exposure Procurement teams that accept a clean SOC 2 report as evidence of trust are relying on reviews that cannot show which actions came from agents.
An auditor tests two things: whether a control meets a criterion, and whether it operated throughout the review period [9]. The column asks about a third test the audit leaves out, which is whether the design is still relevant [9]. In its 10:03 example, the reviewer who approved the engineer's access was right by the control's own terms [3].
The row is produced before anyone files an access request. An agent exists once a developer clicks "Allow" on an OAuth screen, pastes an API key into a config file or adds an MCP server to a JSON file, and nobody is asked to approve it [5]. It usually has no named owner. Someone reconstructs one later from keys and repositories tied to a person, and in the review spreadsheet that guess looks the same as a recorded owner [6]. Then it acts under that person's name [7]. "This will pass the review, while absolutely ignoring the security differences between people and agents," the column says [12].
The column ties the gap to SOC 2's access criteria, CC6.1 through CC6.3, and lists four assumptions that held while every actor was human: someone approves an account before it exists, every account has a known owner, the name in the log identifies the actor, and an account's permissions describe a fixed job [4][10]. It calls the log-name assumption "the expensive one" [13].
What is public here is an argument and an illustration. The 10:03 row is a constructed example, and the column cites the Cloud Security Alliance figure without describing the study's sample or method [3][8].
The criteria can already reach agents [1]. The column's complaint is that they leave the choice to companies and auditors, and that this discretion lets an agent add risk without failing a single control [2]. "If SOC 2 lets you get away with this, the framework either needs to change or risk becoming outdated," it says [14].
What to watch
- Any revision of, or official guidance on, the Trust Services Criteria that names AI agents as a distinct identity class.
- Publication of the Cloud Security Alliance study's sample and method, which would show how far the two-thirds figure extends.
- An audit exception or incident report in which agent activity under a human credential was the finding.