ISJ hears exclusively from Adrian Furtuna, Founder and CEO of Pentest-Tools.com about why the distinction between automated and autonomous defines the future of offensive security.
Walk into any vendor booth at a security conference right now and you will hear some version of the same pitch: AI-powered, autonomous, next-generation offensive security.
The language has converged, but the underlying technology has not.
Behind that shared vocabulary sits a wide spectrum of products, some genuinely novel, many not and the word “autonomous” has been stretched to cover all of them.
This matters more than a branding complaint.
Security leaders are making procurement decisions based on autonomy claims that can sometimes outpace what these tools actually deliver and may not fully reflect what these tools actually do.
When those decisions play out in production environments, the gap between the promise and the reality erodes confidence in automation broadly, including the parts that genuinely work and genuinely help practitioners.
The distinction worth drawing is simple: automation means a practitioner scripts the logic and the tool executes it faithfully.
Autonomy means the system figures out the logic itself.
These are fundamentally different things, and each has a legitimate role in a mature security programme.
The problem is that a part of the offensive security industry has found it commercially convenient to blur that line, which makes it nearly impossible for security teams to evaluate which approach actually fits their needs.
What automation actually does well
Automation in offensive security has a real job, and it does that job well.
The work that skilled practitioners spend hours on before the interesting work begins, recon sequences, tool chaining, scan scheduling, subdomain discovery, port scanning, service fingerprinting, web scanning across all discovered ports, is high-volume, rule-based and does not require judgment.
Automation handles it reliably, at scale, without fatigue.
Testing templates are a concrete illustration of this.
A well-designed template can automate chained testing sequences that cover the manual, repetitive work in a standard engagement – subdomain discovery, port scanning, service fingerprinting, web scanning across all discovered assets – all without requiring any AI reasoning.
The logic is fully transparent and practitioner-defined, the output is deterministic and auditable, and nothing in that workflow requires AI to reason about anything.
The practitioner scripts it, the template executes it faithfully and the practitioner interrogates the results.
That model works because it is honest about what it is.
Automation gives skilled practitioners back the time they need to do the work that machines genuinely cannot: subjective judgment, creative exploitation, chaining vulnerabilities in ways no predetermined rule set would anticipate.
The goal of good automation is to accelerate the human, not to replace the human’s role in producing a defensible finding.
Where AI earns its place in the workflow
AI has specific, bounded roles where it adds real value in offensive security, and they are worth taking seriously.
The clearest example is signal-level noise reduction.
HTTP responses at scale produce a classification problem that exhausts rule-based logic: distinguishing genuine findings from soft-404 pages, false positives and instrumentation noise.
An ML classifier that handles this semantically, rather than through regex or static rules, can achieve meaningful results, with some implementations delivering 50% false positive reduction and 92% precision.
The AI is not “understanding” the web application.
It is handling a well-defined classification problem that static rules handle poorly at scale.
Another is crawling coverage.
AI can map logical flows inside web applications, improving what a deterministic scanner can reach and surfacing hidden endpoints that a standard crawl would miss, without replacing the scanner’s validated outputs.
What AI does not reliably do today is independently reason about novel attack paths, chain vulnerabilities across complex environments, or produce findings that do not require human validation before they reach a client or a developer.
Products that claim otherwise owe their users a detailed, reproducible proof of those capabilities.
The evidence standard offensive security has always applied to findings should apply equally to the tools producing them.
Why the distinction matters for how security teams are structured
Autonomous systems are optimised for coverage and speed.
Offensive security is optimised for accuracy, evidence and defensible findings.
Both of those things have value, but they serve different contexts and conflating the tools that deliver them makes it harder for teams to deploy either well.
The specific challenge with autonomous findings is the validation burden they introduce.
A system that generates a finding without a human in the loop pushes the validation step downstream, onto the analyst who receives the output.
In a high-noise, high-pressure environment, that step often does not happen the way it should.
Teams act on findings prematurely, or the team loses trust in the signal and dismisses things they should be investigating.
Understanding where autonomous tooling fits, and where it creates friction, is a design decision that should be made intentionally rather than inherited from a vendor’s positioning.
Human-in-the-loop is a deliberate design choice, not a limitation of current technology.
Offensive security works the way it does because a skilled practitioner needs to own the finding, understand its context and stand behind it.
Good automation and good AI compress the time it takes to reach that moment.
The question for each team is where that moment needs to sit in their workflow.
What practitioners should demand from the tools they evaluate
Three questions worth asking of any product that claims AI or autonomous capabilities in offensive security.
First: Which parts of the workflow run deterministically, and which parts does AI control? If the vendor cannot answer this precisely, the architecture is probably not as controlled as they claim.
Vagueness here is a signal.
Second: How does the tool handle validation? Does it produce theoretical findings or does it generate evidence? A finding without proof is a hypothesis.
Practitioners get judged on what they can demonstrate. The tools they use should meet the same standard.
Third: What does “human-in-the-loop” actually mean in this product? Is human approval a real gate on tool execution, or is it a disclaimer in the documentation? The MCP server model, where every tool call requires explicit approval and executes against a strict schema, is one concrete example of what genuine human oversight looks like in practice.
It is worth asking what the equivalent looks like in any tool under evaluation.
The distinction that enables better decisions
The offensive security industry has spent decades building rigorous standards for evidence, scope and validation.
Those standards exist because the work has consequences.
A finding that cannot be reproduced or defended is not a finding.
An engagement that cannot be audited is a liability.
Both automation and autonomous capabilities can serve those standards, in the right contexts and with the right design choices.
The conflation of the two is what undermines them, because it prevents security teams from asking the questions that would help them deploy each approach well.
Knowing whether a tool is executing practitioner-defined logic or reasoning independently determines whether a workflow stays auditable, whether findings stay defensible and whether the practitioners running it retain professional ownership of the results they deliver.
Getting precise about that distinction is not a technical footnote.
It is how security teams make decisions they can stand behind.
