This week is less about whether AI can find vulnerabilities and more about what happens when you give it enough time, context and infrastructure to keep looking. What I like about this week’s selection is that none of it relies on the usual “the model is getting smarter” story. The interesting shift is that security work that used to be limited by human time, cloud costs or specialist availability can now be repeated for hours or days. The systems are still imperfect, but they are becoming cheap and persistent enough to inspect everything, revisit weak signals and keep going long after a human would have moved on.

Joseph Thacker and JD spent five months building a hackbot that reportedly found 126 vulnerabilities, including 88 rated High or Critical. Of those, 77 were accepted or remained in triage, 35 were duplicates, and only 14 were closed as Informative or Not Applicable.

But before you start thinking, “Cashiiiinn!!”, you need to read the full article. The numbers are not the most interesting part. What makes it worth reading is everything that initially failed.

Their first version produced a beautiful dashboard full of vulnerabilities, most of which disappeared under basic scrutiny. The bot would test a few things, accept the first plausible explanation, and move on. Adding more instructions did not fix it. They needed complete logs to understand what the agent was actually doing, loops that forced it to keep investigating weak signals, and an orchestrator that could decide when a target was worth more time.

Even then, roughly 80% of the raw findings were false positives. Their solution was another agent whose job was not to find vulnerabilities, but to aggressively disprove them. That reduced the false-positive rate to around 60%.

The biggest improvement was even less glamorous: authentication. At one point, 80% of their tokens were being spent trying to log in through headless browsers. They eventually dedicated a physical computer with a real Chrome profile to maintaining authenticated sessions and passing fresh tokens to the cloud agents. Once the bot could reliably stay logged in, it started reaching the IDORs and broken access control issues where much of the real impact was found.

This matches one of the problems we saw two weeks ago in the YouTube video “Building an AI Pentesting Platform”: getting an agent to the interesting parts of an application often requires solving authentication, sessions, 2FA and all the other boring operational problems first.

That is, once again, the main takeaway. The model matters, but most of the work required to turn it into a useful security researcher sits around the model: observability, persistence, authentication, target selection and adversarial validation. The hackbot was not created by writing the perfect prompt. It was created by repeatedly identifying where the agent behaved unlike a real hacker and building the infrastructure needed to compensate. The Bug Bounty Singularity: Our Hackbot.

Eddie Zhang tested several AI-assisted approaches against an unpublished authenticated file inclusion vulnerability in phpIPAM. At the time of the test, there was no CVE, advisory, public patch or write-up for the models to repeat. The vulnerability has since been disclosed as CVE-2026-12194.

Semgrep missed it. An autonomous Strix run missed it after almost 12 hours and 60 million tokens. Frontier models found it inconsistently. A local model with a much simpler harness found it every time.

The difference was coverage. The harness walked through the repository file by file, and almost every model identified the vulnerability when the review reached the relevant file. The local model was not necessarily smarter. It simply made a brute-force, 120-million-token review economically reasonable.

That economic shift may be the most interesting part. With cloud models, every additional file, retry and validation step costs money. When the model runs locally, the marginal cost is mostly electricity and the FOMO that the GPU could be finding better bugs somewhere else. You can afford to review every file, rerun the analysis with different prompts, revisit weak findings and leave the system working on a project for days.

For an AppSec team with some GPU capacity and dozens or hundreds of microservices to review, this could be a very practical approach. Not every service needs a brilliant autonomous agent with a complete understanding of the business. Many services are small enough that something patient can inspect every file, flag suspicious code, and repeat the process after every meaningful change.

The same harness was later run against myVesta, where it found a previously unknown authenticated command injection within eight hours. That issue was patched and assigned CVE-2026-12195.

Local AI does not make the analysis free, and compute is still finite. But it changes the constraint from “How many tokens can I afford?” to “How much time am I willing to spend on this target?” For security research and large AppSec teams, that is a significant change. Local AI for Penetration Testing & Research.

Two weeks ago, we covered Patch the Planet, the collaboration between Trail of Bits and OpenAI. This new field report gives a better idea of what the work actually looked like against zlib.

GPT-5.5-Cyber concluded that another static review of such a heavily reviewed project was unlikely to be productive. It switched to dynamic testing, created sanitizer builds, reused existing tests as seeds, tested compile-time variants and wrote harnesses covering around a dozen entry points.

More importantly, it handled part of the triage. One test produced a crash in inflateBack, but the model determined that it required an unrealistic state created by the caller and was unlikely to be reachable in practice. Once a fuzzing campaign is running, producing crashes is largely automated. Determining which of those crashes represent real vulnerabilities is where much of the expert time goes, and GPT-5.5-Cyber seems capable of handling part of that work now.

If both the setup and triage of a bespoke fuzzing campaign can be reduced from weeks of specialist work to a day of agent time, fuzzing becomes practical against far more targets for both defenders and attackers. GPT-5.5-Cyber built a zlib fuzzing lab in a day.

Security Context is an interesting idea. It analyses a repository’s previous vulnerabilities and security fixes, then turns that history into context an AI agent can use during a review. Running it against Rails, for example, gives you recurring areas of weakness and potential locations where variants of old bugs may still exist.

This is exactly the sort of context agents are currently missing. We give them coding conventions, architecture documentation and instructions for running the tests, but rarely explain how the application has been broken before. For security reviews, that history may be more valuable than another generic secure-coding checklist, especially if, like me, you believe that bugs usually come in swarms: https://pentesterlab.com/blog/code-review-catch-a-swarm-instead-of-a-bug

However, there is a privacy trade-off that is easy to overlook. When your agent queries the remote MCP server, it sends the repository it is investigating and can request specific variant leads or severity levels. The repository may be public, but your decision to investigate it is not. Over time, those requests could reveal which projects you are researching, when you started looking at them, and which leads were interesting enough to revisit.

For ordinary AppSec work, that may be an acceptable trade. For unpublished vulnerability research where secrecy matters, I would prefer to download the context once, or generate it locally, rather than leave a remote MCP connected throughout the investigation. The context an agent needs to find the next vulnerability..