SOC 2 in the age of agentic attacks

SOC 2 answers a specific question: did the controls you described exist and operate during the audit period? It answers it with evidence: policies, screenshots, tickets, access reviews. That was a reasonable standard when attacks were run by people who also worked office hours. In 2026, the attacker is a model that tests every control, every day, and does not care what the auditor saw in March.

The gap between evidence and truth

Consider a common control: "access to customer data is restricted to authorised users". The SOC 2 evidence is an access review and a policy document. The agentic-attack test is: create a free account, request another customer's record by ID, see what comes back. Both can be true at once. Vercel had a compliance programme. It was entered through an OAuth token granted to a note-taking tool nobody had assessed.

From screenshot to test result

The fix is not to abandon SOC 2 but to change what the evidence is. Each control maps to one or more plain-English rules, each rule has a test that runs against the live product, and the evidence for the control is the test result, timestamped, on every release. The auditor receives a control map backed by live results. Vendor questionnaires get the same answer, and it is current.

• →CC6.1 logical access → "a user must never act on another user's account", tested per release.
• →CC6.6 external threats → "no unauthenticated endpoint returns customer data", tested per release.
• →CC7.2 monitoring → "a failing rule blocks the release or pages a human", with the log to prove it.
• →CC8.1 change management → "every change is tested against every rule before deploy", with the pipeline run as the evidence.

Every company on the record had a security team. What every one of them lacked was a rule for this.From the MATT home page

Why auditors are starting to ask

Auditors read the same disclosures everyone else does. After a year in which three frontier labs reported their own models breaching third parties, "show me the access review" is a harder question to ask with a straight face than "show me the test". Firms are beginning to accept, and in some cases prefer, continuous test evidence for technical controls. Enterprise buyers moved earlier: security questionnaires increasingly ask how often controls are tested, not whether they exist.

The practical path

• →Take your current SOC 2 control list and mark which controls are technical and testable. In most products it is a majority.
• →Write each as a rule and a test. The first pass will surface controls that were described but never actually verified.
• →Run the tests on every release and keep the results. Hand the auditor the map. Hand the customer the same map.

Compliance and security were always supposed to be the same thing. Live test evidence is how they become the same thing again.