Why AI Cannot Replace Human Led Penetration Testing: A Field Report from PlutoSec

Every few months another product arrives promising penetration testing on autopilot. Point it at your application, walk away, and come back to a clean bill of health. It is an appealing pitch, and inside the narrow band of work these tools genuinely handle well, they earn their place in the toolkit. But after years of running engagements against web applications, APIs, cloud platforms and internal networks, the cyber security team at PlutoSec keeps arriving at the same uncomfortable conclusion. The vulnerabilities that actually get organizations breached are almost never the ones a scanner flags.

This is not an argument against automation. Automated tooling runs on every engagement we deliver at PlutoSec. What follows is a field report on where those tools stop, why they stop there, and what a human led penetration testing approach catches that no AI scanner, as of today, reliably can.

Why Penetration Testing Matters Before Any of This

It is worth restating why penetration testing exists at all, because the answer explains most of the disagreement that follows.

A vulnerability scan answers a narrow question: does anything here resemble a problem someone has already catalogued? A penetration test answers the question your board, your auditors and your customers actually care about: can a motivated attacker get in, and how far can they travel once they are inside? Those are not the same question, and only the second one describes a breach.

There is a compliance dimension too. PCI DSS, SOC 2, ISO 27001 and HIPAA all expect evidence of periodic testing performed by qualified people, not a scanner subscription and a screenshot. And the arithmetic is not subtle. A thorough engagement costs a fraction of a single incident response retainer, let alone the regulatory exposure and customer churn that follow a public compromise. Most organizations that come to PlutoSec are not asking whether they have vulnerabilities. They already assume they do. They are asking which ones a real adversary would actually reach for. That is a different question, and it needs a different method.

What Automated Scanners And AI Tools Actually Do Well

Fairness before criticism. Scanners and the current generation of AI assisted security tools are genuinely excellent at one specific job, which is pattern matching at scale.

Point one at a large attack surface and it will dependably surface known CVEs, outdated components, missing security headers, default credentials, unauthenticated SQL injection, reflected XSS in simple parameters, weak TLS configurations, and services sitting on the public internet that were never meant to be there. It does this across thousands of endpoints in minutes, and it never gets tired, distracted or bored.

For coverage, regression checking and continuous monitoring, that is real value. At PlutoSec we run this tooling deliberately, early, and with clear expectations of what it is for: clearing the noise floor so our testers can spend their hours on depth rather than breadth. The failure mode is not using scanners. The failure mode is mistaking breadth for a finished assessment.

The Core Limitation: Scanners Match Patterns, They Do Not Understand Intent

An automated tool, even a modern AI driven one, measures your application against a library of known bad signatures and heuristics. Its underlying question is always some version of: does this look like something already on my list?

A human attacker asks something else entirely. What is this application meant to do, and how do I convince it to do something it was never designed to do?

That gap, between recognizing a pattern and understanding intent, is precisely where the most damaging vulnerabilities live. These flaws are invisible to signature matching because they are not bad code. They are perfectly valid code being used in a way nobody anticipated. No signature exists for a legitimate feature being abused.

The categories below are ones where our testers have repeatedly watched automated tooling report no issues found on systems that were, in fact, critically exposed. Details are generalized, but the patterns repeat across client after client.

1. Business Logic Flaws

This is the single largest blind spot in automated testing, and it is where hands on web application penetration testing consistently earns its keep.

On one ecommerce engagement, every scanner we aimed at the checkout flow came back clean. No injection, no XSS, no misconfiguration. Then a tester walked the purchase workflow by hand and noticed the discount coupon was validated client side and only loosely rechecked on the server. By intercepting the request and firing the same single use promo code across parallel connections, an attacker could stack it until the cart total went negative, at which point the store was effectively paying people to check out.

There is no CVE for “your discount logic can be stacked.” A scanner has no concept of what a coupon is supposed to do, so it cannot recognize the abuse. A human who understands the business model finds it in twenty minutes.

2. Broken Access Control and IDOR

Insecure Direct Object References and broken authorization sit near the top of almost every real breach analysis, and they are notoriously difficult for tools to detect with any confidence.

The reason is context. A scanner watches a request to an invoice endpoint return a 200 and records a successful request behaving as intended. It has no way of knowing the invoice belongs to a different customer, and that the account making the request should never have been able to see it. Telling authorized access apart from unauthorized access that happens to succeed requires knowing who is supposed to see what, which means understanding the permission model of the application itself.

On a SaaS engagement our team provisioned two low privilege accounts and methodically swapped identifiers between them. Automated tooling had already reported those endpoints as functioning normally. Manually, we pulled another tenant’s financial records, exported their user list and modified their settings, a complete horizontal privilege escalation across tenant boundaries. Every individual request looked like a success to a machine. Only a person comparing what should have been visible against what actually was could see the breach.

3. Chained and Multi Step Exploits

Scanners assess findings in isolation. A low severity information disclosure here, a medium severity misconfiguration there, next item. What they almost never do is connect those findings into a single attack path.

Real intrusions are rarely one clean exploit. They are chains. A verbose error message leaks an internal hostname. That hostname points to a forgotten staging service. The staging service still runs a default credential. Those credentials turn out to be reused on something that matters. Rated individually, each link is low or informational. Assembled by someone thinking like an attacker, they are a full compromise.

This is a reasoning and creativity problem more than a detection problem. It means holding the whole system in your head and asking what happens if these three unremarkable things are combined. That synthesis is exactly what current AI tooling struggles with, and exactly what an experienced tester does by reflex.

4. Race Conditions and Timing Attacks

Plenty of high impact vulnerabilities only surface under precise timing conditions that scanners never reproduce. Submitting the same withdrawal, gift card redemption or referral bonus simultaneously across dozens of parallel connections can slip straight past checks written on the assumption that requests arrive one at a time.

Finding this requires forming a hypothesis about how the backend handles concurrency and then deliberately engineering the conditions to test it. A scanner sending sequential requests will never trigger it, because it is not trying to. It never had the hypothesis in the first place.

5. Second Order and Stored Vulnerabilities

Some injection and logic flaws do not fire where the input goes in. They fire later, somewhere else entirely, when the stored data is processed by a different component. A payload dropped into a notes field may do nothing at all on submission and then execute when an administrator opens a report that renders that field in another context days afterwards.

Tracing input from entry point to eventual sink, across features and often across days, is a tracking and reasoning task automated tools handle poorly. Humans follow the data.

Where These Blind Spots Show Up: Web, API and Network Testing

The gap between pattern matching and intent is not abstract. It looks different depending on what is being tested, and the three surfaces PlutoSec spends most of its engagement hours on each fail in their own way.

Web application penetration testing

Modern web applications are stateful, heavily authenticated and full of multi step workflows. That is the environment scanners handle worst. A crawler that cannot maintain a session, complete an onboarding sequence or reach step four of a checkout simply never sees the pages where the interesting flaws live. In web application penetration testing, our testers authenticate as several different roles, drive the workflows manually, and attack the logic underneath rather than the input fields on top: privilege boundaries, password reset and multi factor flows, file upload handling, server side request forgery in integrations, and the session management that ties it all together.

API penetration testing

APIs are where the most severe modern findings tend to concentrate, and where automation is least useful. There is no user interface to crawl, so a scanner only ever sees the endpoints you hand it, and it has no view of the documentation, the schema or the business rules behind them. Broken object level authorization, broken function level authorization, mass assignment, excessive data exposure and unrestricted resource consumption all look like ordinary successful traffic to a tool. Our API testing at PlutoSec works from the specification and the client applications together, enumerating undocumented and shadow endpoints, abusing object identifiers across accounts, tampering with GraphQL queries, and testing whether the authorization checks that exist in the web front end were ever implemented behind it. In most engagements the answer is that some of them were not.

Network penetration testing

On external and internal networks, a scanner gives you an inventory. It does not give you an attack path. Network penetration testing is about what happens after the inventory: relaying authentication, cracking and reusing credentials, abusing misconfigured directory permissions, pivoting between segments that were assumed to be isolated, and escalating from an ordinary workstation foothold to domain wide control. Every one of those steps is a decision made in response to what the previous step revealed, which is why the output of a network scan and the output of a network penetration test rarely resemble one another.

Grey Box and White Box Testing: Where Scanner Dependency Hurts Most

Engagements are usually scoped as black box, grey box or white box, and the amount of value a scanner can contribute drops sharply as you move along that scale.

In a black box test, the tester starts with nothing but a domain name, the same as an anonymous attacker. Automation still helps here, because the first job is mapping unknown surface area.

Grey box testing is where most serious engagements land. The tester receives credentials for several roles, a rough architecture overview and some documentation, which is a realistic model of the attacker who has phished one employee or bought one set of credentials. This is precisely the setting where scanner dependency becomes dangerous. Authenticated, multi role, workflow driven testing is where business logic flaws, IDOR and privilege escalation live, and it is exactly the territory automated tools cannot navigate. A scanner pointed at a grey box scope will still report on headers and outdated libraries while walking past the endpoint that lets one customer read another customer’s data.

White box testing goes further, adding source code, infrastructure configuration and design documentation. Static analysis tools have a real role here, but they produce enormous volumes of theoretical findings with no sense of which ones are actually reachable in a running system. The value comes from a human reading the authorization logic, tracing user controlled input from entry to sink through the actual code, and then proving exploitability against the live application. That combination, code review paired with hands on exploitation, is what turns a list of possible issues into a short list of confirmed ones.

The pattern across all three is consistent. The deeper the access, the less a scanner contributes and the more the outcome depends on the person holding the keyboard. Reducing that dependency is a deliberate methodology choice at PlutoSec, not a stylistic preference: tooling is used to establish coverage, and human testers decide what is real.

Hundreds of Exploits, Driven by Hand

There is a practical dimension to human led testing that gets less attention than the reasoning argument, and it matters just as much. A skilled tester carries an enormous working library of offensive technique: hundreds of documented exploits drawn from public and private databases, exploit frameworks, published research and techniques traded within the security community, along with the judgement to know which handful of them apply to your particular stack, your particular versions and your particular configuration.

Scanners carry libraries too, but they only fire what fits a matched signature. A human adapts. An exploit written for a slightly different version gets modified. A technique from an unrelated technology gets ported across. A public proof of concept that fails in your environment gets debugged until it works, because the tester understands why it failed. And when the application is custom and nothing off the shelf fits, which describes most of the software our clients actually care about, PlutoSec testers write exploits by hand for that specific code, that specific logic and that specific architecture.

This is the part AI tooling has not closed. Current models are bounded by the patterns they were trained on. Inventing a novel exploit for a one of a kind application, and then refining it against defences that push back, is still something an experienced human does considerably better, and it happens to be where the highest impact vulnerabilities tend to hide.

AI Scanning vs Human Led Penetration Testing: A Side by Side Comparison

The quickest way to see the gap is to set the two approaches next to each other. The table below compares automated and AI driven scanning against human led penetration testing across the factors that decide whether a real attacker gets in.

Capabilities	AI and Automated Scanning	Human Led Penetration Testing
Coverage and Speed	Sweeps thousands of endpoints in minutes and never tires. Ideal for breadth and continuous monitoring, but the coverage is wide and shallow.	Focused and deliberate. Less ground per hour, far more depth on the areas that matter, following the attack paths a real adversary would take.
Business Logic Flaws	Largely blind. A tool has no concept of what a feature is meant to do, so it cannot recognize that logic is being abused.	Core strength. Testers understand business context and intent, uncovering coupon stacking, workflow abuse and pricing manipulation that no signature exists for.
Broken Access Control and IDOR	Frequently missed. A successful request looks healthy to a tool, even when it is returning another customer’s data.	Reliably found. Testers compare what should be visible against what is visible across multiple accounts and roles to catch privilege escalation.
API Testing	Sees only the endpoints it is handed. Undocumented routes, mass assignment and object level authorization gaps read as normal traffic.	Works from specifications and client applications, enumerates shadow endpoints, and tests authorization at the object and function level.
Network Testing	Produces an inventory of hosts, ports and known CVEs with no sense of how they connect.	Produces an attack path: credential reuse, relaying, lateral movement and escalation from a single foothold to domain control.
Grey and White Box Depth	Value drops sharply with deeper access. Cannot navigate authenticated multi step workflows or judge which code level findings are reachable.	Value rises with deeper access. Credentialed, multi role testing and code review paired with live exploitation confirm what is genuinely exploitable.
Chained and Multi Step Exploits	Assesses findings in isolation and rarely connects them. Low severity issues stay low severity on the report.	Synthesizes minor findings into full attack chains, demonstrating how small issues combine into a real compromise.
Accuracy and False Positives	Prone to false positives that flood reports with noise and consume developer time.	Every meaningful finding is manually verified and, where safe, exploited to prove real impact.
Creativity and Context	Matches known patterns. Cannot form a hypothesis or improvise the way an attacker does.	Thinks like an attacker, forms hypotheses and tests the unexpected. This is where the most damaging flaws are found.
Cost and Value	Low cost and fast, but a clean scan can manufacture false confidence about true exposure.	A higher investment that reflects real risk, delivering findings and remediation guidance automated tools cannot produce.
Reporting	Generates a raw list of alerts and CVSS scores with little business context.	Human written reports explain why each issue matters to your business, with clear reproduction and remediation steps.

The takeaway is not that one replaces the other. Automation gives you breadth. Human led penetration testing gives you the depth and judgement that actually reflect how a breach happens.

How a PlutoSec Engagement Actually Works

So how does a team find what scanners miss? A strong methodology front loads the human reasoning that tools cannot replicate, and treats automation as an input rather than an answer.

Reconnaissance and context building first. Before anyone touches an exploit, our testers learn what the application does, how the business makes money, what the user roles are, where the money flows and where the trust boundaries sit. You cannot abuse logic you do not understand. This phase is almost entirely human.

Automated tooling for coverage, not conclusions. Scanners run early to map the attack surface and dispose of known issues quickly. Their output is a starting point and a list of things to investigate. It is never the assessment.

Manual exploitation and validation. Every meaningful finding is verified by hand and, where safe to do so, exploited to demonstrate real world impact. This removes the false positives that clutter automated reports, and more importantly it surfaces the logic and authorization flaws that were never on any scanner list to begin with.

The attacker perspective and a deep exploit arsenal. This is the edge tooling cannot copy. A skilled tester brings a genuinely adversarial mindset, the same lateral thinking a real attacker uses to look at a system and ask not what is broken here, but what can I turn against you. Sitting on top of that instinct is the accumulated offensive knowledge described above, plus the willingness to write something new when nothing existing fits.

Attack path thinking. Lower severity findings are deliberately chained to model how an adversary would actually move through the environment, rather than reported as isolated issues that look harmless standing alone.

Human written reporting. A good deliverable explains not only what is broken but why it matters to this specific business, with reproduction steps a developer can genuinely follow and remediation guidance tailored to the stack in front of them. A CVSS score and a stack trace are not a remediation plan. Every PlutoSec report is written by the tester who did the work.

Where AI Fits: Augmentation, Not Replacement

None of this means AI has no place in offensive security. The honest position, and the one held across the security practice at Pluto IT Solutions, is that AI is a force multiplier rather than a substitute. It accelerates reconnaissance, helps sift enormous volumes of output, drafts payload variations, and frees skilled testers to spend their limited hours where human judgement is irreplaceable.

The tester who uses AI well outperforms the tester who ignores it. But AI alone, pointed at an application with nobody driving it, will keep returning no critical issues found on systems a determined attacker would walk straight through. The gap is not about model size or training data. It is that the highest impact vulnerabilities are defined by intent and context, and abusing intent remains, for now, a distinctly human skill.

The Bottom Line

Automated and AI driven scanning tells you whether your application resembles known bad patterns. Human led penetration testing tells you whether a motivated, creative adversary can actually break in. Those are different questions, and only one of them reflects the cyber security threat your organization genuinely faces.

If your last penetration test was a scan report with a nice PDF cover page, you do not yet know what a real attacker could do with your systems.

This article was contributed by the offensive security team at PlutoSec (Pluto Security), part of Pluto IT Solutions, a human led penetration testing and cyber security firm working across web application, API, cloud and network security. Learn more at plutosec.ca, plutosec.us and plutosec.uk.