In 2024, Google's Big Sleep project discovered a previously unknown stack buffer underflow vulnerability in a widely used database engine (SQLite) without human intervention. The significance is substantial: a language model read the codebase, formed a hypothesis, wrote and executed a scenario to test that hypothesis, and arrived at a real vulnerability. Around the same time, a tool called XBOW climbed the leaderboards on HackerOne with a similar claim: autonomous pentest, that is, scanning a target and constructing exploit chains without a human operator. I cannot definitively verify a product called "Mythos" that's mentioned; I'm not confident about it, so I'm proceeding with examples I know and can back up with publicly available sources.
To satisfy my curiosity, I set up a similar experiment in my own lab: I placed an open-source web application with known vulnerabilities (OWASP Juice Shop) alongside an open-source LLM-based scanning tool. I approached the experiment like a postmortem: what did I expect, what happened, why.
Impact
Within a three-hour scanning window, the tool independently found two of Juice Shop's known vulnerabilities (a SQL injection and an IDOR—object access without authorization checks) and produced a validating payload for each. A third, more complex logic flaw (business logic flaw) it attempted repeatedly but could not validate; it only flagged it as "suspicious." The impact is mixed: the tool saves real time, but it's not reliable without human oversight.
Timeline
About twelve minutes after scanning started, the tool found the first vulnerability (SQL injection). At the thirty-fourth minute, it detected the IDOR. For the remaining two and a half hours, it ran attempts against the third target but got no results. The speed is impressive on easy, templated vulnerabilities; but as vulnerability complexity increases, time grows not linearly but exponentially.
To keep the lab setup simple, I used this docker-compose snippet:
services:
juice-shop:
image: bkimminich/juice-shop:v17.1.1
ports:
- "3000:3000"
networks:
- labnet
ai-scanner:
build: ./scanner
environment:
- TARGET_URL=http://juice-shop:3000
- MAX_ITERATIONS=200
depends_on:
- juice-shop
networks:
- labnet
networks:
labnet:
driver: bridge
This configuration runs the target application and the scanning tool on the same isolated network; no ports are open to the internet, so the experiment stayed completely controlled.
Root cause — why some things were found and others weren't
As the tool analyzes the codebase and HTTP traffic, it relies on pattern matching and the model's inference that "this behavior is anomalous." Vulnerabilities like SQL injection and IDOR are patterns with plenty of examples in the literature and thus well-represented in training data. But the third scenario—where a user adds a product to cart but the price calculation is validated client-side rather than server-side—is pure business logic flaw. To find that, the tool would have to truly "understand" the application's workflow, not just hunt for syntactic anomalies. The model's limit is clear here: it's strong at pattern recognition, still fragile at contextual reasoning.
During these experiments, one of the requests the tool generated triggered a warning on the server. The JSON record looked like this:
{
"timestamp": "2024-11-03T14:22:07Z",
"event_type": "web.request.anomaly",
"source_ip": "192.168[.]1[.]50",
"destination_ip": "192.168[.]1[.]100",
"method": "GET",
"path": "/rest/products/1/reviews' OR '1'='1",
"status_code": 500,
"user_agent": "ai-scanner/0.9 (lab-test)",
"rule_triggered": "sql_injection_pattern",
"severity": "high"
}
This record shows the tool attempting a classic SQL injection payload and the server meeting it with a 500 error code. The first signal that the vulnerability existed actually came from the server's error message, not from the tool's own "intelligence." The tool still relies on classical security signals—error codes, timing delays, response differences; there's no magic understanding at work.
What worked
On recurring, well-documented vulnerability classes, the tool genuinely saved time. It scanned and prioritized dozens of endpoints that a human pentester would manually traverse and test, all within minutes. For each vulnerability it found, it generated a working validation request, keeping the false positive rate low—two out of three vulnerability claims actually held up.
What didn't work
The tool struggled predictably with logic-based vulnerabilities. During scanning, it repeated some requests needlessly, testing the same payload in minor variations dozens of times, showing inefficient resource use. It sometimes overstated the severity of a finding—flagging a low-impact information leak as high-risk because it cannot judge how sensitive the data actually is.
General takeaway
It's too early for these tools to completely replace security teams; but I think they're a serious candidate for the first scanning layer—the work of picking low-hanging fruit. This is not a prediction, just an observation from my own lab run. As these tools improve their business logic comprehension—especially as they become able to model an application's state machine, that is, which operations must happen in which order—they will likely reach more complex vulnerabilities. But as of today, advanced vulnerability discovery remains a field where human intuition and machine speed work together; neither has replaced the other.