Misconception: SOC 2 requires a human consultant to run your penetration test, no exceptions. Nowhere in the Trust Services Criteria does it say that — but the belief is common enough that it catches teams off guard. More security teams are running continuous, AI-driven penetration testing year-round instead of commissioning a single annual engagement — and then arriving at their SOC 2 audit with a question their auditor hasn't been asked before: will you accept a penetration test report where the testing was performed by an AI agent, not a human consultant?

Does SOC 2 accept AI-conducted penetration tests? Yes, but with conditions — let's see which ones actually matter to an auditor.

The rest of this article works through why that's true: what SOC 2 actually requires, why continuous AI testing fits the audit period better than an annual pentest does, and what separates AI-generated evidence an auditor will accept from AI-generated noise they'll reject.

SOC 2 Doesn't Actually Say “Penetration Test”

This surprises people the first time they read the Trust Services Criteria closely. The AICPA defines the Trust Services Criteria in TSP Section 100 (the 2017 criteria, with revised points of focus issued in 2022). Read the official documentation carefully, and you will see that the text never mandates a penetration test by name. What it mandates is that an organization evaluates whether its controls are operating effectively, and penetration testing has become the market-standard way auditors expect that evaluation to happen for technical controls—not because the framework requires that specific method, but because nothing else demonstrates a control actually holds under attack rather than just existing on paper.

Three criteria carry most of the weight:

Criterion	What it requires	Why testing method is how auditors evaluate it
CC4.1 — Monitoring activities	The entity evaluates whether its controls are present and functioning	Inspecting a control (reading a config, checking a policy doc) confirms it exists; attacking it confirms it works
CC7.1 — Vulnerability identification	The entity identifies vulnerabilities in its infrastructure	Implies an ongoing activity — vulnerabilities don't appear on a fixed annual schedule, so evidence needs to cover the audit period, not one date within it
CC7.2 — Security event detection	The entity implements detection procedures to identify anomalies	A live attack is one of the only ways to generate a real event and observe whether detection actually fires

So "we need a pentest for SOC 2" is really shorthand for "we need credible evidence that our controls survive an active attempt to break them, across the period being audited." That distinction matters, because it means the auditor's real question was never who or what ran the test — it's whether what came out of it is credible, reproducible evidence of control effectiveness. An AI agent is judged against exactly the same bar a human tester is.

Type II Audits Are Built for Continuous Evidence, Not a Single Snapshot

SOC 2 comes in two flavors, and the difference changes what "acceptable evidence" even means.

• Type I attests that controls were suitably designed at a single point in time.
• Type II attests that controls operated effectively across an audit period — typically six to twelve months.

A traditional annual penetration test produces one data point: a report dated some day inside that window. For a Type I audit, that's a reasonable fit. For a Type II audit, it's a structural mismatch — one snapshot is being asked to stand in for twelve months of control operation, and everything that happened before or after that engagement's dates is simply unevidenced.

This is where continuous, AI-driven testing changes the shape of the evidence rather than just its volume. Because an agentic pentesting platform can run recurring test cycles across the audit period instead of one engagement inside it, the evidence trail naturally spans the same window the Type II opinion is attesting to. A new CVE disclosed in month seven of the audit period gets tested against your environment in month seven, not discovered retroactively when next year's annual pentest happens to catch it. That's a better structural fit for what a Type II audit is actually trying to prove — not a shortcut around the requirement, a closer match to it.

What Criteria Must an AI Pentest Report Meet for SOC 2?

For a SOC 2 audit, the tool that produced a finding is not the auditor's real concern. Auditors already accept plenty of automated input (vulnerability scanners, config-compliance tools, log-based monitoring) as supporting evidence. What determines whether a penetration test report — AI-run or human-run — holds up is the same short list of properties:

1. Reproducible proof, not a severity score. A finding needs a request/response pair, a reproduction path, or another artifact a third party could use to independently confirm impact — not a confidence rating attached to a pattern match.
2. A documented, inspectable methodology. The auditor needs to be able to read what was actually tested — which entry points, which hypotheses, which validation steps — rather than take a black-box "trust the model" claim on faith. Auditors are professionally skeptical of black boxes for good reason.
3. Named, accountable human sign-off. Somewhere in the chain, a specific, qualified person reviewed the results and is accountable for the report's accuracy — exactly as a human-run engagement would name the tester who signed it.
4. A defined, agreed scope. Which systems the program covers, over what period, and how that maps to the audit boundary. Undefined or shifting scope undermines evidence quality regardless of who ran the test.
5. Consistency of evidence format across the period. If the evidence a Type II audit relies on changes shape halfway through — different report structure, different coverage, no explanation — that reads as a red flag, not as innovation.

Here's what points 1 and 2 look like in practice, from a real Broken Object-Level Authorization finding on a mobile backend — endpoint names, tokens, and identifying values are redacted.

Figure 1: The finding itself — severity, a plain-language description of the flaw, and a root-cause confirmation showing the vulnerable endpoint ignores a header that a comparable endpoint correctly enforces. The rest of the figures below trace how this specific finding was planned, reproduced, and revalidated.

Figure 2: The first two steps of the reproduction path — a global bearer token obtained from hardcoded client credentials, then a request payload encrypted to match the target's scheme. Redacted for publication.

Figure 3: The response the request in Figure 2 actually produced — a full PII object returned for a valid account, with no user token supplied. This is the "reproducible proof" from point 1: a third party can rerun this exact request and get the same result.

Figure 4: The testing plan behind the same finding — a named planning agent, explicit objectives (confirm the header bypass, verify the token is sufficient, check persistence across rotations, and so on), and a phased task list starting with baseline documentation and attack-surface mapping. This is what point 2 means by "inspectable": an auditor can read exactly what was planned and tested, not just the result.

None of these five properties are specific to AI. They're the same bar a mediocre human pentest report also fails on — vague findings with no reproduction steps, a subcontractor nobody can name, scope that was never written down. AI-conducted testing doesn't get graded on a curve, and it doesn't need to: agentic testing that actually validates its findings clears this bar more consistently than either a rushed manual engagement or a signature-based scan.

Where “AI-Conducted” Quietly Fails as Evidence

The failure mode worth watching for isn't "the auditor rejected it because AI was involved." It's mistaking an AI scanner for an AI pentest, and handing the auditor the former labeled as the latter.

A scanner — AI-assisted or not — pattern-matches against a codebase or a live target and reports what it thinks might be wrong. Left unvalidated, that output is a list of hypotheses, not findings: high false-positive volume, no reproduction path, no evidence that anything demonstrated real impact. That's weaker audit evidence than a modest human pentest, not stronger, because a reviewer still has to redo the work to know what's real. Scanning more of the attack surface at once doesn't change that math either — running multi-asset scanning across web, mobile, and API assets in parallel just produces more unvalidated hypotheses per hour unless something downstream actually confirms which ones are real.

An AI pentest is different in kind, not just in speed: recon, hypothesis, test, validate, and — critically — a step that asks whether one finding combines with another into something more serious. The distinction that matters for CC7.1 evidence specifically is whether the report shows a credential was proven live against a real endpoint, or just flagged as "possible hardcoded secret." One is proof; the other is a lead that still needs a human to chase down.

This is the same principle Ostorlab's Agentic Deep Scan is built around for exactly this reason: a detection phase finds and exploits the issue, producing a runnable request, the response it produced, and the specific claim that response substantiates. A separate validation phase then re-runs the exploit independently before a human ever sees it — a fresh token, not the one already in hand; a comparative check against an endpoint that enforces the control correctly, to rule out a global misconfiguration; alternate input formats and repeat runs over time, to confirm the issue isn't a fluke of one specific request. That's the difference between evidence an auditor can act on and a report that just moves the verification work downstream.

Figure 5: The validation phase for the same finding — the exploit rerun across a batch of accounts to rule out a one-off result, then repeated with a newly obtained token to confirm the issue isn't tied to the original session. This runs after detection and before the finding is ever surfaced to a human.

The Evidence Package an Auditor Actually Wants to See

Whether the testing was continuous or a single engagement, human-run or AI-run, a Type II-ready evidence package generally needs the same components:

Component	What it demonstrates
Methodology document	What was tested, how, and by what process — including how the AI agent's hypotheses were generated and validated
Scope statement	Which systems, environments, and time window the testing program covers, mapped to the audit boundary
Per-finding proof	Request/response pairs, reproduction steps, screenshots, or logs showing real impact — not a severity label alone
Human review record	Who reviewed the findings, when, and what judgment they applied — the named accountability an auditor can reference
Remediation and re-test evidence	Confirmation that reported issues were fixed and that the fix was independently re-verified, not just marked closed
Coverage map	Which parts of the audit period the testing evidence actually spans, so gaps are visible rather than assumed away

If a program can produce all six for the full audit period, the fact that an AI agent ran the individual test cycles is an implementation detail, not an objection.

Introducing Continuous AI Testing Without Derailing an Existing Audit

The practical mistake isn't running AI-driven testing — it's changing the shape of your evidence mid-audit-period without telling anyone. A few things make the transition smooth instead of a surprise:

• Talk to your auditor before the period starts, not when the report is due. Most auditors have no objection to more and better evidence; they object to evidence that shows up in an unfamiliar format with no warning.
• Show a sample report early. Let them see what a finding looks like — proof included — before it's the only evidence backing a control.
• Agree on cadence and format in advance. Weekly, continuous, or monthly test cycles are all workable; what breaks trust is switching formats partway through without documenting why.
• Keep a familiar anchor if your auditor wants one. Some firms are still more comfortable with an annual, more heavily human-reviewed engagement as one instance inside a continuous program, at least for the first cycle. That's a reasonable transitional step, not a concession that AI testing doesn't count.

Where This Is Still Unsettled

AICPA's Trust Services Criteria don't yet contain explicit language about AI-conducted testing, and auditor firms vary in how much AI-agent involvement they're comfortable evaluating today. Compliance automation platforms that feed evidence directly into SOC 2 audits have already started accepting AI-conducted penetration test reports as valid supporting evidence — the tooling side of the market is moving ahead of the standards language, even if individual audit firms still set their own bar case by case. Some will accept a well-evidenced AI pentest report with minimal friction; others will ask for a named, credentialed human to review and co-sign the findings before they'll rely on it — which is a reasonable ask, and worth planning for rather than resisting. Until the guidance catches up to the practice, the safer posture is to over-document: keep the methodology explicit, keep a human accountable for every report, and treat auditor pushback as a scoping conversation, not a rejection of the approach.

FAQ

Does SOC 2 require a penetration test? Not explicitly. The Trust Services Criteria require evidence that controls are effective (CC4.1) and that vulnerabilities are identified (CC7.1), and penetration testing has become the accepted way to produce that evidence — but it's an auditor expectation built on the criteria, not a named requirement in the framework text.

Can an AI agent's findings satisfy CC7.1 evidence requirements? Yes, if the findings are validated rather than raw model output: each one needs a reproducible proof of exploitability, not a severity score assigned to a pattern match. Unvalidated AI-generated leads don't meet the bar any more than an unvalidated scanner alert would.

Is a fully autonomous, unreviewed AI pentest report acceptable for SOC 2? Generally no. Auditors expect a named, accountable person behind any report they rely on. An AI agent can run the testing; a qualified human still needs to review and stand behind the results.

How is an AI pentest different from a vulnerability scan for compliance purposes? A scan reports what might be wrong; a pentest — AI-run or human-run — proves what is actually exploitable through recon, hypothesis, test, and validation. Auditors treat unvalidated scan output as weaker evidence because it still requires a human to determine what's real.

Should we keep an annual manual pentest alongside continuous AI testing? Many organizations do, at least during the transition, either because their auditor wants a familiar anchor point or because a periodic human-led engagement adds judgment-based testing (business logic, social engineering-adjacent scenarios) that complements systematic AI coverage rather than duplicating it.

The Bottom Line

SOC 2 was never grading the tool — it was grading the evidence. A penetration test conducted fully by an AI agent can satisfy a SOC 2 Type II audit, and in some respects fits the period-based evidence model better than a single annual engagement does, because continuous testing naturally spans the window the audit is attesting to. What it can't do is skip the parts that were never about the tool in the first place: reproducible proof, a methodology an auditor can actually read, a named human who stands behind the report, and a scope everyone agreed on before the clock started. Get those right, and whether the testing ran on a schedule set by a consulting firm or by an agent reasoning through hypotheses at 2 a.m. stops being the interesting question.

The more interesting question is what happens when the same logic gets applied outside SOC 2. PCI DSS, HIPAA, and the rest of the compliance alphabet lean on the same idea — controls that hold up under attack, not just controls that exist on paper. Whether they're ready to accept an AI-run answer to that question is one we'll take on in another article.