The model is the reasoning component. Everything that makes a test real lives outside it.
Every AI penetration testing pitch now leads with the model. Point the strongest frontier LLM at your application, the story goes, and pentest quality follows. Buyers have started evaluating vendors the same way: which model is behind the agent, and is it the newest one.
It is the wrong question. A frontier model reasons about targets, drafts exploit strategies and writes readable findings with real skill. What it cannot do is act. It cannot send an HTTP request, hold state across a hundred-step attack chain, enforce a scope boundary, or produce a tamper-evident log. A penetration test is not a reasoning exercise. It is a live interaction with production infrastructure, and plausibility is not proof.
In FireCompass testing, a plain frontier model with tools connected produces a result we call X. The full FireCompass harness produces about 3X to 10X that result, depending on task class. For reference, a new frontier model typically delivers about 2X over its own previous generation. The gap between vendors is not the model. It is the engineering around it.
What AI penetration testing actually requires
AI penetration testing uses AI agents to discover an application’s attack surface, plan and execute attacks against it, validate each finding with a working proof of exploit, chain validated findings into multi-stage attack paths, and produce evidence a security team and an auditor can act on. The model reasons. A harness of tools, orchestration and controls does everything else.
That last sentence is the whole argument. Read the list again and mark which items a language model performs. Discovery needs crawlers and request engines. Execution needs a runtime. Validation needs a comparison against a live response. Chaining needs persistent state. Evidence needs capture at the execution layer. The model contributes to planning and interpretation at each step and performs none of them. This is the same separation that underpins continuous automated red teaming and adversarial exposure validation: reasoning proposes, execution proves.
Four gaps no model closes
Each of these is an engineering problem. None is a reasoning problem, which is why a smarter model does not move any of them.
Execution. Models generate text. An exploit payload from a model is a string, not an exploit. Delivering it to a live target, observing the response and deciding whether exploitation succeeded requires a runtime the model has no connection to. That runtime also needs awareness the model lacks: an endpoint that returned 200 now returns 403, a firewall dropped a payload mid-chain, a session token expired. Multi-step attacks need that feedback wired directly into the decision loop.
State. Enterprise attack chains run 30 to 100 or more discrete steps: discovery, enumeration, credential extraction, authentication, privilege escalation, lateral movement, data access. Holding coherent state across a chain that long is not a context-window problem a larger model solves. Inside a conversation, models hallucinate prior steps, forget discovered credentials and contradict earlier decisions, and the longer the chain the worse it gets. Coherence requires a structured state machine that records what was tried, what worked, what was blocked and which credentials are held, independent of the model’s conversation history.
Validation. Models are probabilistic. Asked to find vulnerabilities, they produce confident, syntactically correct findings that are sometimes simply wrong: vulnerabilities that do not exist, paths that are blocked, results that cannot be reproduced. Without a layer that tests every finding against the live system, unvalidated model output lands in the same 50 to 70 percent false-positive range as a traditional scanner. Every model output is a hypothesis until execution proves it.
Safety and governance. A model given aggressive objectives attempts aggressive techniques, because it optimizes for task completion, not infrastructure safety. Left unbounded, that means uncontrolled request rates, write operations that corrupt data and brute-force attempts that lock accounts. The model has no concept of scope: given execution, it follows attack paths into out-of-scope systems, production databases and third-party services. And it produces outputs, not logs, while DORA and PCI DSS 4.0 expect retained, structured evidence of testing. Safety, scope and auditability have to be enforced below the model, where they cannot be reasoned around.
Is agentic AI pentesting the same as DAST?
No. Dynamic application security testing (DAST) is a class of scanner that sends predefined payloads to a running application and pattern-matches the responses. It exercises the application from the outside, which is the right vantage point, but it does not reason about the application, does not chain findings, and reports without proving exploitability, which is why DAST false-positive rates sit at 40 to 70 percent.
Agentic AI pentesting also tests the running application from the outside. The difference is what happens between request and report: an AI agent plans attacks against the specific application, validates each finding with a working exploit, and chains validated findings into the multi-stage paths an attacker would actually take. That is the model behind FireCompass agentic AI web application pentesting. The comparison below is the one buyers should run.
| DAST scanner | Manual penetration test | Agentic AI pentesting (FireCompass) | |
|---|---|---|---|
| Tests the running application | Yes | Yes | Yes |
| Reasons about the specific application and its workflows | No | Yes | Yes |
| Business logic and authorization testing | No | Yes | Yes |
| Proof of exploit for every reported finding | No | Usually | Yes, every finding |
| Multi-stage attack chains, app-to-app and app-to-network | No | Rarely, scoped out | Yes |
| False positive rate | 40 to 70 percent | Low | Below 2 percent |
| Cost per application | $1,460 to $2,900 | $2,400 to $10,000 | $450 to $2,500 |
| Cadence | Continuous, but noisy | Annual, 2+ weeks lead time | Always-on discovery plus on-demand tests |
The false-positive row is the tell. Unvalidated model output and DAST scanners land in the same range for the same reason: neither proves what it reports. The number moves only when a validation layer sits between the hypothesis and the report.
Run a free AI penetration test on your own application.
See the validation evidence for yourself. FireCompass Explorer gives you free pentest credits, so you can point our agents at an application you own and review every finding with its proof of exploit.
How harness engineering closes the gap
Harness engineering is the discipline of building the system around the model. A harness has three moving parts, and result quality depends far more on how well they are engineered together than on which model sits at the center.
- Models. Not one but several, each routed to the task class it handles best, plus purpose-built small models for high-volume work.
- Tools. Crawlers, request engines, browser automation, credential and session handlers, evidence capture. The things that turn a proposed action into a real interaction with a live target.
- Orchestration. Sequences the tools, holds their output in a persistent state store, feeds it back into the reasoning loop, and enforces the scope, rate and safety boundaries the model has no concept of.
The clearest way to hold this is an engine and a vehicle. An engine generates power but has no wheels, steering or brakes, so on its own it goes nowhere. The frontier model is the engine. The harness is the vehicle: the drivetrain that turns reasoning into motion, the steering that keeps it in scope, and the brakes that stop it before it does harm. A vehicle without an engine is inert. An engine without a vehicle is uncontrollable. It is also what separates the open-source AI pentesting tools from a platform you can point at production.
In practice an AI penetration test runs through five stages, and the harness owns every one:
- Discover the surface. Crawl and enumerate subdomains, endpoints, APIs and authentication surfaces, including shadow assets outside the initial scope definition.
- Plan and execute attacks. The intelligence layer generates a structured hypothesis; the runtime delivers the exploit against the live target under scope and safety controls, capturing the exact request and response.
- Validate with proof of exploit. The response is evaluated against the expected exploitation signature. Ambiguous results are re-tested. Findings that fail are discarded, not reported as low-confidence noise.
- Chain into multi-stage paths. Validated findings feed a chain agent that attempts credential reuse and application pivoting, so a medium-severity information disclosure becomes the critical path it actually is.
- Report with evidence. Reproduction steps, request and response pairs, working PoC code and an append-only audit log, from one data model, for both executives and engineers.
How FireCompass built the harness
FireCompass built this harness over several years, combining offensive security expertise with frontier model integration. Four parts matter most to a buyer.
Multiple models, routed by task, plus our own small models. No single frontier model is optimal for every task in a penetration test. FireCompass maintains a model registry, evaluates candidates continuously against internal security benchmarks, and routes hypothesis generation, chain construction, exploit code and context analysis to the model that performs best for each. Because intelligence is separated from execution, a new frontier model is integrated without changing a line of execution infrastructure. Alongside those, FireCompass built its own small language models for high-volume classification and triage. This is partly an accuracy decision and largely an economic one: driving every step through frontier-model tokens makes frequent testing prohibitively expensive, and small-model economics are what make always-on discovery plus on-demand testing affordable at 2,000 applications.
Specialized agents on a shared state store. Surface mapping, reconnaissance, vulnerability assessment, authentication and credential handling, business logic, chain and lateral movement, and evidence collection each run as an independent agent with its own scope validation, rate limiting and audit logging. Agents communicate through a persistent state machine rather than directly, so attack state stays coherent even when an individual agent fails. The architecture is described in more detail on the FireCompass agentic AI platform page.
A four-stage validation pipeline. Hypothesis, live execution, signature evaluation, evidence assembly. This is the mechanism behind the below-2-percent false-positive rate. It is engineering discipline in the validation layer, not model accuracy.
A deterministic safety gateway. No agent action reaches the runtime without passing through it. The governing principle is that a non-deterministic LLM is controlled by deterministic, rule-based systems, never by another model: an input and output firewall around the model, an asset whitelist checked before every dispatch, per-agent capability controls, a token-bucket rate limiter per target host, environment tags on every credential so UAT credentials never reach production, safe-payload rules that block Modify, Update and Delete by default, an operator kill switch, RBAC and ABAC, and a full action audit trail captured by the execution layer as it happens. Every platform action lands in an append-only log with a cryptographic timestamp, supporting DORA, PCI DSS 4.0, SOC 2 Type II and ISO 27001. The same controls are what make continuous automated penetration testing safe to run against live systems, and they cover the OWASP Top 10: 2025 classes an attacker would reach for first.
What the harness changes in production
A Fortune 500 technology company moved from a large consulting firm’s manual program to FireCompass. Cost per application test fell from about $5,000 to under $1,000. Coverage went from 200 of 2,000+ applications a year to the full portfolio. Lead time went from two-plus weeks to on demand. The false-positive rate from supplementary DAST scanning fell from about 70 percent to below 2 percent, and the platform surfaced chained attack paths the consultants had scoped out. The risk and cost trade-offs behind that shift are worth reading alongside this. On public benchmarks, FireCompass agents in fully autonomous mode achieved 104 of 104 on XBEN, 12 of 12 on Acuart with PoC validation, and full coverage across every DVWA difficulty level. Read those as harness outcomes, not model scores.
Benchmarks are controlled environments. HackerOne is not. Between April and July 2026, FireCompass AI agents competed on live, authorized HackerOne programs against the world’s best human researchers and other AI agents hunting the same production targets, and reached the top three across multiple US Business leaderboards, including No. 1 in OWASP A01 Broken Access Control and No. 2 for Highest Critical Reputation. The frontier models behind those agents were available to every entrant. The ranking is a harness result. The full methodology is in our HackerOne write-up.
One boundary, stated plainly: FireCompass does dynamic testing against running applications and APIs. Frontier models alone are stronger at static and code analysis, and FireCompass does not compete there.
The engine is becoming a commodity. The harness is not.
Frontier models are getting more capable, more accessible and more interchangeable. That will not solve autonomous penetration testing, because reasoning is not execution. A model may propose an attack path or infer a vulnerability. It cannot assure exploit validation, operational safety, state persistence, evidence integrity or governed operation. Hypotheses are not vulnerabilities.
So when a vendor leads with the model, ask about the vehicle. Ask to see the state store, the validation pipeline, the kill switch and the audit log. If the answer is a model name, you have found the ceiling of that product, and it is lower than it sounds.
Talk to a Security Expert.
Bring the application you would point any model-first tool at. We run the same target through the FireCompass harness and walk through the validation evidence, the safety gateway decisions and the audit log together.
Frequently asked questions
Can an LLM do penetration testing on its own? No. A large language model generates text. It cannot send requests, hold state across a long attack chain, prove that a finding is exploitable, or enforce scope and safety limits. In FireCompass testing, a full harness produces about 3X to 10X the result of a frontier model used as a plain wrapper with tools connected.
What is harness engineering in AI penetration testing? Harness engineering is the discipline of building the system around the model: the routed models, the tools they drive, and the orchestration that sequences actions, holds state, validates findings and enforces scope, rate and safety controls. It is the layer that turns model reasoning into a validated, safe, auditable test.
Is agentic AI pentesting the same as DAST? No. DAST scanners send predefined payloads and pattern-match responses without proving exploitability, which is why their false-positive rates sit at 40 to 70 percent. Agentic AI pentesting plans attacks against the specific application, validates every finding with a working exploit, and chains findings into multi-stage attack paths, at a false-positive rate below 2 percent.
Why do AI pentesting tools have high false-positive rates? Because unvalidated model output is a hypothesis, not evidence. Without a validation layer that executes each candidate finding against the live system and checks the response against an exploitation signature, model output lands in the same 50 to 70 percent false-positive range as a scanner.
How does an AI pentesting platform stay safe on production systems? Through deterministic controls enforced below the model: an asset whitelist checked before every action, per-host rate limits, environment-tagged credentials, safe-payload rules that block destructive operations by default, an operator kill switch, and an append-only audit log. A non-deterministic model should never be the thing that decides scope or safety.
Does a better frontier model make AI penetration testing better? Only at the margin. A better model raises the ceiling on reasoning and does nothing for execution, state, validation or safety, because those are harness properties. A new frontier model typically delivers about 2X over its predecessor; a well-engineered harness delivers 3X to 10X over a plain model with tools.
What does an AI penetration test cost compared with a manual pentest? FireCompass costs $450 to $2,500 per application against $2,400 to $10,000 for a manual penetration test. A Fortune 500 technology company cut cost per test from about $5,000 to under $1,000 while expanding coverage from 200 to more than 2,000 applications.
About FireCompass
FireCompass is an Agentic AI platform for autonomous penetration testing and red teaming across Web, API and infrastructure. It discovers shadow assets and web applications, safely validates what is exploitable, and connects findings into multi-stage attack paths with near-zero false positives. Unlike traditional scanners, it discovers credential reuse, business-logic flaws, privilege escalation, and app-to-app or app-to-network lateral movement. It can operate autonomously or with expert-in-the-loop validation. FireCompass has 30+ analyst recognitions across Gartner, Forrester, IDC, and is trusted by Fortune 100 enterprises. Try it free at firecompass.com/explorer.
