SOC 2 Doesn't Cover AI Agents. Here Is the Audit That Does

Two audits failed in October, in the same way.

A flaw in PHP, the software behind a large share of the world's websites, had passed a 2024 security audit: the auditors saw signs of it and found no way in.¹ This month, researchers using AI models found the way. Wiz, one of the teams involved, says a single researcher did in a week what would have taken a world-class team months.² Attack attempts were showing up within about twenty minutes of the fix.¹

Days earlier, a researcher found that eight signing keys at eMudhra, a certificate authority that browsers trust, were tiny numbers. One of them was 4.³ In the company's own words: "The issue went undetected for about 18 months, through two independent audit cycles."⁴

The lesson is not that audits are useless. It is that an audit checks whether a process was followed, and an attacker, now with AI doing the legwork, checks whether the result is safe. For a firm putting an AI agent on client files, that is exactly the gap a SOC 2 report leaves open.

What a SOC 2 report doesn't test

SOC 2 is the security report a vendor hands over in due diligence. An independent auditor confirms that the vendor's controls match the AICPA's criteria and, in a Type II report, that they worked over a period of months. It is worth asking for.

It says nothing specific about AI agents. The criteria were last substantively revised in 2017,⁶ and the AICPA's September guidance keeps AI inside the existing categories. As one audit firm put it: "The Trust Services Criteria has not been rewritten for AI."⁵ A vendor can also leave its AI model provider out of the audit as a subcontractor.⁵ The Cloud Security Alliance's conclusion in August: "no common AI baseline exists for auditors to test against."⁶

So a clean report can't tell you what an agent can read, where it can send what it reads, or what happens when a document from the other side carries instructions meant for the AI. Those are the questions that matter once a tool can act instead of only answer.

The AI Agent Security Audit

The AI Agent Security Audit is ten tests, each run against the live system by an engineer who watches it pass or fail. It is a procedure, not a questionnaire. Northwood runs it on every deployment it ships, the same way every time, and the procedure is published here for any firm or provider to use:

1. Specify. Before anything is built, the security terms in the client's contract become numbered requirements. Each of the ten tests maps to them.
2. Build in the client's repository. The environment is defined as code in a repository the client owns, so the thing tested is the thing deployed, and every change has a history.
3. Test before go-live. The ten tests run on the real deployment before any client document goes in. Each result, with its evidence, goes into a results record in that repository.
4. Re-run after every change. Every update re-runs the tests. A test that passed before and fails now blocks the release. The full set also runs every quarter.
5. Leave the record with the client. The repository, the results and the right to re-run any test stay with the client, with or without the provider.

Why these ten? The tests follow from the three things an agent can do: read the client's files, read content written by outsiders, and send information out.⁷ All three together is how files leak: a line hidden in an outside document tells the agent to send something, and it can. Switch off any one of the three and the leak closes, but only the way out can go without losing the work. Tests 1 to 3 check that it is gone. Tests 4 to 8 settle who and what the agent can reach, and who answers for it. Tests 9 and 10 cover fixes, recovery and exit.

How to use it alongside SOC 2

If you buy an AI tool, ask for both. The SOC 2 report covers the vendor's organization and the cloud it runs on. The audit covers the agent: what it can reach, what it can send, and who answers for it. Send the ten questions and ask for results with evidence. A vendor that shows eight passes and a date for the other two is in better shape than one with a spotless report and no test results.

If the AI runs inside your own cloud account, tests 1 to 3 are largely settled by construction: there is no provider account for data to sit in, and no route out for a planted instruction to use. The other seven still have to be run, and re-run.

Comments on the tests go into version 1.1, with credit.

Sources

1. The Hacker News, "PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge" (October 21, 2026): https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html
2. Wiz Research, "PHP2Shell: AI uncovers critical RCE vulnerabilities" (October 21, 2026): https://wiz.io/blog/php2shell-php-rce
3. The Register, "eMudhra's private keys compromised: one of them was the number 4" (October 20, 2026): https://www.theregister.com/security/2026/10/20/indian-certification-authority-emudhras-private-keys-compromised-one-of-them-was-the-number-4/5304312
4. eMudhra, "Statement on Recent Certificate Security Incident" (updated October 22, 2026): https://emudhra.com/en/post/certificate-security-incident
5. Schneider Downs, "AI in SOC Examinations: What the AICPA's New TQA Section 9561 Means for Service Organizations" (September 30, 2026): https://schneiderdowns.com/our-thoughts-on/ai-in-soc-examinations-what-the-aicpas-new-tqa-section-9561-means-for-service-organizations/
6. Cloud Security Alliance AI Safety Initiative, "The SOC 2 AI Gap: Auditors Improvise Where AICPA Has Not Acted" (August 30, 2026): https://labs.cloudsecurityalliance.org/research/csa-research-note-soc2-ai-controls-gap-20260830-csa-styled/
7. Simon Willison, "The lethal trifecta for AI agents: private data, untrusted content, and external communication" (June 16, 2025): https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/