Automated Pentest: What It Finds, What It Misses
- BreachVex runs an automated pentest that finds access-control, injection and misconfiguration flaws on its own, and misses what needs a human's model of the business.
- An agent replays real attacks against a URL, six of the ten OWASP Web categories are targeted today, and the result carries the request that produced it.
- The gap is not quality. It is the kind of question being asked: the agent can settle whether a flaw is exploitable, and cannot decide whether your approval flow makes business sense.
- Use the automated run between manual engagements, not instead of them.
What "automated" changes
Two tools get called automated and they do different work. A DAST scanner sends requests and matches responses against known patterns; the output is a list of places that look wrong. An automated pentest attempts the attack itself, and the finding arrives with the request that worked. The difference is not the severity of what gets found; it is whether anyone still has to prove the result before fixing it. Exploit validation versus scanning goes through that distinction in detail.
What it finds without help
The parts of a web application that can be reasoned about from the outside are the parts an agent covers well. On our own coverage page, six of the ten OWASP Web categories are actively targeted today, alongside the API and LLM pillars (read on breachvex.com on 23 October 2026).
- Surface mapping. Routes, parameters, API versions, JavaScript bundles that name internal endpoints, and the authentication mechanism in use. A route the crawler never finds is a route nobody tests, so this stage decides how much of the rest is possible.
- Object-level access control. IDOR and BOLA are mechanical once two accounts exist: change the identifier, compare the responses. This is where an agent is often better than a human on a deadline, because it will try every identifier instead of the three that look interesting.
- Injection, including the blind variants. SQL, NoSQL, command, template and LDAP injection, with out-of-band callbacks for the cases where nothing comes back in the response body.
- Authentication and session handling. JWT algorithm confusion, weak secrets, session fixation, account enumeration, and what happens to a session that already existed when the password changed.
- Server-side request forgery. Internal service probing and cloud metadata endpoints, confirmed by a callback rather than inferred from an error message.
- Misconfiguration. Debug endpoints, verbose errors, permissive CORS, missing headers, and credentials left in client-side bundles.
- Documented business logic. Discount stacking, quota reuse, workflow steps taken out of order. An agent can walk these because the rule is written into the code and reachable by replaying a sequence. That is different from knowing which sequence your finance team intended.
- Chains inside one session. A low-privilege account plus a mass-assignment flaw plus an admin endpoint is a path an agent can try end to end without getting bored at step two.
Where it stops
The honest list is longer than the marketing version usually admits.
- A rule nobody wrote down. If the approval step matters because of a policy in someone's head, the agent sees a working request, not a violation.
- Cross-role chains that need intent. Deciding that a support user, a refund, and a retry endpoint add up to fraud requires knowing the business, not just the code.
- Source-level flaws. Blackbox testing sees behaviour. It cannot see the branch nobody deployed, the module only reachable behind a feature flag, or the dependency that ships in a build you never ran.
- Novel research in third-party software. An agent applies known classes of attack. It does not discover a new vulnerability in a library.
- Internal network and Active Directory. The pipeline runs from the outside. Lateral movement, segmentation and domain controller paths need a different vantage point and a different engagement.
- Social engineering and physical access. Phishing, pretexting and walking into a building are human exercises with their own authorisation and their own risks for the people involved.
- Impact in your context. A finding arrives with a severity vector. It does not arrive with the knowledge that this endpoint handles refunds for your largest customer.
- Compliance-mandated independence. Where a framework asks for a qualified, organisationally independent tester, an automated run does not satisfy it. The penetration testing page sets out what such an engagement covers.
Why the proof changes the queue
Triage is where the cost of security tooling hides. A candidate queue has to be read by a person before a single ticket is filed, and an afternoon of reading turns into a week when the queue is mostly noise. A reproduced finding is a different object: it carries the request, the response, and the effect, so the question becomes whether to fix it rather than whether it is real.
That is also why our queue is scoped rather than universal. A finding reaches the priority queue once the exploitation has been reproduced. What the pipeline cannot reproduce lands in a separate, labelled annex with its reason attached, instead of being promoted or quietly deleted.
| What you run | What comes back | FP rate | What it costs your team |
|---|---|---|---|
| Manual engagement | Reproduced findings and a written report | Rare, and a person reproduces each one before it is written up | Weeks of preparation, plus the retest |
| DAST scanner | Candidates matched against known patterns | High — every candidate needs a human to confirm it | Triage time, every cycle |
| Automated pentest (BreachVex) | Findings that reached the queue once reproduced, plus a labelled annex | proof-gated queue | Reading a shorter queue |
Where it fits in a test programme
An automated run is a cadence tool. It is worth most on the deploys between engagements, when a manual report is already describing code that has changed, and it is worth least as a substitute for the engagement itself.
The pattern that holds up: one manual engagement a year on the part of the product where a human's judgement pays for itself, and automated runs on everything that ships in between. What the two cost, and how the billing units differ, is laid out in what a pentest costs and in the scan pricing breakdown. If you are still deciding which of the two you are buying, what is automated penetration testing is the definitional version.
Sources
- breachvex.com, coverage section, read 23 October 2026: the six OWASP Web categories actively targeted, the API and LLM pillars, and the advanced techniques listed beyond them.
- breachvex.com/pricing, read 23 October 2026: what one credit covers, and the founding and standard scan prices.
- Penetration testing: what a test covers, published 19 October 2026: the scope boundaries this page refers to, and the compliance position.
- OWASP Web Security Testing Guide: the reference for the test categories named above. No figure on this page comes from it.
Next step
The cheapest way to find out whether an agent covers your case is to point it at one application. Our own prices, founding rate and standard rate, are on the pricing page, and the penetration testing page is the document to read before you commission a manual engagement on top.
BreachVex is in early access: join the waitlist and we will write when your access opens.
Frequently Asked Questions
- What does an automated pentest find that a scanner does not?
- A scanner matches patterns and hands back candidates. An automated pentest attempts the attack and keeps the request that worked. In practice that changes access-control results most: object-level authorisation, mass assignment and privilege boundaries become reproducible findings instead of suspicions. It changes the queue more than it changes the category list.
- What does an automated pentest miss?
- Anything that needs a model of your business rather than of your code. A rule nobody wrote down, an approval step whose order matters to finance but not to the compiler, a chain that only makes sense once you know what each role is allowed to do. It also misses source-level flaws in code that was never deployed, social engineering, physical access, and anything on the internal network.
- Can it replace a manual penetration test?
- No. Where a framework or a customer asks for an independent, qualified tester, the automated run does not answer that requirement, and no amount of engineering changes it. The automated run covers the deploys between engagements, when the last report is a snapshot of code that has moved.
- Why does proof of exploitation matter for triage?
- Because triage is where the cost hides. A queue of candidates has to be read by a person, line by line, before anyone can decide what to fix. A queue of reproduced findings arrives with the request that produced each one, so the decision is whether to fix it, not whether it is real.