AI can find the bugs. Pentesters know which ones matter

On 22 October 2026 Daniel Stenberg, who started curl in the late 1990s and still leads it, wrote that in the last few months his project had received hundreds of vulnerability reports and that every one of them had AI involved in some way (Stenberg). Nine months earlier he had shut curl's bug bounty for the opposite reason: the AI reports were mostly rubbish. Somewhere between those two posts, the machines got good at finding bugs. What they still can't do well is the part a company actually pays a penetration tester for, and that's what this piece is about.

What a pentest looked like in 2024

Two years ago, if you hired someone to test your systems, you got people. A small team agreed a scope with you, signed rules of engagement, and spent a week or two attacking whatever you'd agreed they could attack. They used scanners for the boring parts and their own heads for everything else. Then they wrote a report, usually a long PDF, with each finding rated by severity and a section at the front for the people who'd never read the rest.

Most companies didn't do it at all. In the UK government's latest breaches survey, only 13% of businesses said they'd had a penetration test in the past year (DSIT). In the US the main driver for a lot of firms was, and still is, the card industry's PCI DSS standard, which asks for internal and external testing at least once every 12 months, by a "qualified internal resource or qualified external third-party" who is independent of the systems being tested (requirement 11.4, as reproduced by Microsoft). Once a year, by a person. That was the shape of it.

AI was around, but on the edges. At the start of November 2024 Google's Project Zero and DeepMind said their agent, Big Sleep, had found a real, exploitable bug in SQLite, the small database built into a huge number of apps and devices. They said they believed it was the first public example of an AI agent doing that in widely used software. They also wrote, in the same post, that these were "highly experimental results" and that a fuzzer built for the job would probably have done at least as well (Project Zero). Mozilla had been experimenting too, with models like GPT-4 and Claude 3.5 Sonnet reading Firefox code. It later described the results as promising but buried in false alarms, too many to be worth scaling (Mozilla). At the end of 2024, then, AI in testing was interesting and occasionally impressive, but not something you'd bet a contract on.

2025, the year the machines started climbing the leaderboards

In June 2025 a company called XBOW announced that its autonomous system had reached the top of HackerOne's US leaderboard, the public ranking of people who find bugs for bounty programmes. XBOW says it was the first time a machine had done that (XBOW). XBOW sells the product, so it had every reason to make noise about it, and it did. Its own write-up is worth reading closely, though, because the detail is more interesting than the headline. XBOW sent in nearly 1,060 reports. Its security team reviewed every one before submission, because HackerOne's rules on automated tools required it. And when you look at what happened to those reports afterwards, only a minority ended up fixed.

We don't read that as a failure. Plenty of human hunters would be pleased with 130 fixes. We read it as a picture of what raw findings look like: a lot of real problems, a lot of duplicates, and a lot of things that are true but don't matter to the owner.

In August 2025, at DEF CON, DARPA announced the winners of its two-year AI Cyber Challenge. The finalists' systems were set loose on 54 million lines of open-source code with vulnerabilities planted in it. They found 54 of the 63 planted flaws and patched 43, and along the way turned up 18 real ones nobody had planted (DARPA). In October HackerOne's annual report counted more than 560 valid reports from fully autonomous "hackbots", and found that 70% of the researchers it surveyed now used AI in their work (HackerOne).

And in December a team from Stanford, Carnegie Mellon and Gray Swan AI ran the test everyone had been waiting for. They put ten professional penetration testers and a set of AI agents on the same live university network, about 8,000 machines, and scored them the same way (Lin et al.). We'll come back to what happened, because it says more about the job than any leaderboard.

2026, when the reports stopped being rubbish

The clearest story of 2026 happened inside Firefox. In February Anthropic's red team sent Mozilla a batch of bugs found with Claude Opus 4.6, 22 of them over two weeks (Anthropic). Mozilla fixed them. Then it built its own pipeline, which was the important part. Models ran in parallel across many machines, each hunting through one file and writing test cases it could run to check whether a suspected bug was real. When Mozilla got the chance to try Anthropic's Claude Mythos Preview in the spring, it dropped the new model into the same pipeline. Firefox 150, released in April, carried fixes for 271 bugs it had found, 180 of them rated high severity (Mozilla).

Some of what the models found had been sitting in the code for 15 or 20 years, in a browser that Mozilla and outside researchers have been fuzzing for years. Mozilla's engineers wrote that the models also got better at explaining what they'd found, not just finding it. And they wrote something else that's easy to skip past: more than 100 people contributed code to keep up with the fixes. The machines produced the findings. People had to sort them, fix them, test the fixes and ship them, and it took months of long days.

By autumn Anthropic said publicly what the curve looked like on one academic benchmark: models went from finding under 20% of its vulnerabilities at the start of 2025 to over 85% this year (Anthropic). Benchmarks flatter whoever publishes them, and Anthropic sells the models. But Firefox isn't a benchmark, and neither was PHP2Shell, found in August and fixed this week, which we wrote about here.

Anyone can run the tools. That was the problem

The leaderboards leave out what happened next to one of the most useful programs on the internet, and it's the best argument we know for why the human part of testing still counts. curl is a small program that moves data over the internet. It's built into so much other software that Stenberg counts its users in the billions, most of them without knowing it (Stenberg). In April 2019 it started a bug bounty, and for five years it worked. Researchers found 87 real vulnerabilities and were paid more than $100,000 between them. Somewhere north of 15% of the reports curl received turned out to be genuine.

Then, from the second half of 2024, the reports started to change. More and more of them came straight out of AI tools, sent by people who hadn't checked what they were sending. They read well. They named functions, described attacks and sounded exactly like the real thing, and a lot of them were made up. Stenberg's team had to take each one seriously, because occasionally one was real, and debunking a confident fake can take a long time. In 2025 the share of genuine reports fell below 5%. "Not even one in twenty was real," Stenberg wrote when he closed the bounty at the end of January 2026 (Stenberg). That's what "anyone can be a pentester now" looked like in practice. Anyone could generate a finding. Almost nobody generating them could tell whether it was true.

The story didn't end there, which is why it's useful. By October 2026 Stenberg was writing that "the slop reports are practically gone" and had been since the spring. The reports coming in were accurate, often with a working proof attached. His new problem was volume. He also noted two things the models still did badly: they write far too much, and they're still poor at deciding where a bug ends and a vulnerability begins, or how serious a vulnerability is (Stenberg).

Meanwhile the group that has found more curl vulnerabilities than anyone ever had was a company that builds AI tools for finding them. Over about a year its engineers found 35 with their tooling, and Stenberg put the success down to findings "backed up by a team of skilled humans" (Stenberg). Same project, same year, same technology. The difference between the worst reports curl ever received and the best was whether a person who understood the work stood behind them.

Finding a bug isn't a pentest

Back to the Stanford experiment, the closest thing we have to a fair fight. The team's own agent, ARTEMIS, came second overall. It beat nine of the ten professionals and cost about $18 an hour to run, against roughly $60 for a professional tester (Lin et al., a preprint). The six off-the-shelf agents they also tried, including ones from the big labs, did worse than nearly all the humans. On the scoreboard, a clear win for the agent.

Read the paper and two moments stand out. The first is a remote-access device on the network, the kind that lets someone control a Windows machine through a web page. Eight in ten of the human testers found a way to take over that machine through it (Lin et al.). ARTEMIS couldn't work the graphical interface, so it went looking for known bugs in the device's version number instead, found a couple of minor misconfigurations, reported those, and moved on. Left to itself it missed the serious one, and only got there when the researchers gave it hints. The second is a false alarm. ARTEMIS reported that it had logged in with default passwords, because the servers answered with "200 OK". They were redirecting it back to the login page after each failed attempt. A person would have looked at the screen and seen it.

Neither moment is about intelligence. Both are about what the work actually is, which is a slower, fussier and more human business than a leaderboard can show, because most of it happens after the bug is found, in the hours spent proving it, ranking it against everything else and explaining it to someone who has a budget and a board to answer to. A pentest isn't a count of findings. It's a judgement about how someone could hurt this particular company, backed by proof, and written for people who have to decide what to fix first. That means a few things a scanner, or a model on its own, doesn't give you.

It's authorised. In the UK, getting into a computer without permission is a criminal offence under the Computer Misuse Act 1990, and in the US the federal Computer Fraud and Abuse Act does the same job. A test is legal because someone with the authority to say yes agreed in writing to what will be tested, when, and how far. AI agents that wander off the agreed list have already caused real trouble at the labs that build them, which our AI history covers. A tester's first job is keeping the test inside the lines.

It doesn't break things. The Stanford team warned in their method section that large network scans can degrade live services. On a research network set up for a study, that's a footnote. On your payment system on a Friday afternoon, it's an incident.

Every finding is checked. This is where the bottleneck now sits, and the people who build the models say so. On 8 October 2026 Anthropic wrote that its scanning of important open-source projects had produced more than 29,000 candidate vulnerabilities, but people had only been able to review about 6,000 of them, and that "we remain bottlenecked on our human capacity to validate these findings" (Anthropic).

When its own expert testers checked a sample of 97 serious findings, 85 held up, 11 were real but already known, and one was simply wrong. That's a good hit rate. Even so, the maintainers who received the reports told Anthropic two things: severity was sometimes inflated, and the scanner sometimes misunderstood what the project was supposed to protect against. Both are judgement calls, and they're the ones that decide what gets fixed this week.

It's explained in plain language. Anyone who has asked a model to write up a long technical job will recognise the next problem, and we see it in our own day-to-day use of these tools. The write-up covers most of what happened. Then it leaves out one detail, and that detail changes what the finding means. The model wasn't lying. It just didn't know which part mattered. You can reduce this by running the job several times and merging the results, and that works, but it costs time and somebody still has to read the merged version and notice what's missing. A board doesn't need 300 pages that are nearly all right. It needs to know which three things could take the business down and what each one costs to fix.

That's the honest answer to "can anyone be a pentester now?" Anyone can produce findings, and some of them will be real. What a client pays for is the other part: the permission, the care, the checking, the ranking and the explanation. Security teams seem to have reached the same conclusion. In a 2026 survey by Cobalt, which sells human-led testing and so has an interest in the answer, the share of organisations relying entirely on automated AI testing fell from 29% to 9% in a year, and nearly half said they preferred AI combined with human testers (The Register). HackerOne's researchers said much the same in 2025: 58% thought AI misses business logic and chained attacks, and only 12% thought it could replace them (HackerOne).

What 2027 is likely to look like

The UK's National Cyber Security Centre published its assessment of AI and cyber threats to 2027 in May 2025, and it has aged well. It expects AI to make attacks more frequent and more effective, mostly by speeding up techniques attackers already use. It says the gap between a vulnerability being announced and being exploited "has shrunk to days" and that AI will almost certainly shrink it further. It expects a divide between systems that keep up and a large number that don't. And on full automation it's measured: "The development of fully automated, end-to-end advanced cyber attacks is unlikely to 2027. Skilled cyber actors will need to remain in the loop" (NCSC). That last sentence is about attackers, but we think it describes defenders just as well. Here's how we expect testing to change over the next year.

Finding will keep getting cheaper. Mozilla says it plans to scan every code change as it lands, not just whole files on a schedule. Large open-source projects are getting free scanning from the labs. The same tools are available to attackers, which is the whole point of the NCSC's warning.

Once a year will start to look thin. PCI DSS and similar rules will still ask for an annual test, and that won't change in 2027. But when the window between disclosure and attack is days, a test from last March tells you very little about this October. We expect more companies to pair a full test once a year with smaller, more frequent checks in between, with AI doing much of the legwork.

Reports will get longer, and the useful part will get shorter. A model can now produce a very long report overnight. The page that matters is still the one that says what to fix first and why, and that page is written by someone who understood your business well enough to rank the findings.

And the tester's job will change shape. Less time hunting by hand, more time checking what the machines found, connecting small problems into the chain an attacker would actually use, and explaining it to people who don't speak the language. We don't think fewer people will do this work in 2027. We think it'll be harder to do it well, and easier to fake.

What we'd do if we were buying a pentest now

If you're commissioning a test in the next year or so, here's what we'd do. Before signing, we'd ask the provider how they use AI and who checks every finding before it reaches us. Any good tester in 2026 uses AI somewhere, so "we don't" isn't the reassuring answer it sounds like. What we'd want to hear is that a named, experienced person has reproduced each finding and is willing to stand behind it.

We'd ask to see a sample report, and we'd read the first two pages, not the last two hundred. If the summary doesn't tell a non-technical director what matters and why, the rest won't help. We'd also look for proof attached to each finding: the steps, the request, the screenshot, something we could hand to our own developers to see the problem for themselves.

We'd be wary of anything that looks like a scanner's output with a cover page. The Stanford agent's false login is a good test case to keep in mind: a finding that says "default credentials accepted" means nothing unless someone actually logged in.

We'd get the scope and the permission in writing, including which systems are off limits and what happens if the tester finds a way into something that wasn't on the list. And if we were in a regulated industry, PCI DSS in particular, we'd check the tester meets the qualification and independence rules our assessor will ask about.

Last, we'd think about frequency. If our systems change every week, a single test a year leaves a long blind spot. A full test plus lighter checks after major changes is closer to how attackers now work.

The part that doesn't get automated

Two years ago the hard part of a penetration test was finding the problems. Today the machines are good at that, sometimes better than people, and getting better every few months. The hard part has moved to the end of the process: deciding what's real, what's dangerous for this company, and what to do about it, then saying so in words the person paying can act on.

curl's year is the whole story in miniature. The same tools produced the worst reports the project ever saw and some of the best. The difference was the person behind them. Penetration testing is one of the services we offer at Redvault, and this is how we think about it.