AI Penetration Testing: A Founder's Guide

Search this term and page one is almost entirely vendors, each one telling you their platform finds vulnerabilities faster than a human tester. Several of them are telling the truth. None of them answers the question a founder is actually asking, which is whether any of this changes what you have to do on Monday, given that you have no security team and your last penetration test was the one an enterprise customer made you buy.

Here is the short version. AI penetration testing means autonomous agents that find and exploit vulnerabilities in a running system the way an attacker would: from the outside, usually with nothing but a URL, and without a person directing each step. The demonstrations are real and they are not marketing. But the part that should change your planning is not the tool you might buy. It is that the same capability is available to whoever is attacking you, and the cheapest path into your company is probably not a flaw in your code at all.

The short scope, before the detail. An AI pentest gives you continuous black-box testing of the surface you point it at, proof that a weakness is really reachable, and a report you can hand to an enterprise buyer. It will not find the AWS key in your CI logs, vet the dependency your engineer added last Tuesday, or patch anything, and those are the paths an autonomous attacker tries first.

The spine of this article is a talk by Oege de Moor, founder and CEO of XBOW, given at Sequoia's AI Ascent in April 2026 and published that May. De Moor is not new to this problem. He founded Semmle in 2006 as a spinout of the Oxford research group he ran, where he was a computer science professor for more than two decades. GitHub acquired Semmle in 2019, and its CodeQL engine now powers GitHub code scanning, the core of GitHub Advanced Security. He is also selling the product he is describing, so this article separates what XBOW demonstrated from what its CEO is projecting, and pairs both with a conversation between two security founders watching the same shift from the defender's side.

What AI penetration testing actually is

AI penetration testing is the use of autonomous agents to find and exploit vulnerabilities in a running system the way an attacker would: from the outside, usually with nothing but a URL, and without a person directing each step. It is distinct from AI-driven QA testing, which checks that your product works, and from AI code review, which reads your source. This one tries to break the thing you actually deployed.

Start with the boundary, because two very different products are sold under names that sound identical, and founders keep buying the one that does not answer their question.

White box tools read your source code and point at flaws in it. That is the lineage de Moor himself comes from, and he is careful about what it does: it is code analysis, it needs the source, and it produces a list of places where the code resembles a known bug class.

Black box tools attack the running system with no privileged access. De Moor's framing of the difference is the useful part, and it is a set of questions rather than a definition: "are the weaknesses actually exploitable in the wild? And if they are exploitable, does it matter? What's the impact?" He then asks where an attacker can reach next, once inside. He adds the category that source analysis structurally cannot see, which is the large class of vulnerabilities that are "configuration or deployment problems. You can't actually use them from the source code itself."

That last point deserves a founder translation, because it describes most of what breaks in a small company. Your code can be clean and your S3 bucket still public. Your dependencies can be current and your staging database still reachable from the internet with the password you set during the demo. Source analysis reads the repository. It does not know what you deployed.

The mechanism of a black-box agent explains the cost curve. De Moor describes XBOW as working "very much like a human hacker. It starts by reconnaissance. It sends out a bunch of scouts, agents that discover the attack surface." It then prioritizes the endpoints that look most promising and tries every relevant attack type against them. Nothing in that loop is novel as a methodology. What is novel is that the loop runs without a person in it, so its cost per attempt is inference rather than salary.

What AI penetration testing has actually proven

De Moor makes several claims in nine minutes, and they are not all the same kind of claim. Separating them is the most useful thing a reader can do with this talk, so here they are sorted.

Demonstrated and independently reported. In June 2025, XBOW's autonomous system reached number one on HackerOne's United States leaderboard, first reported by Bloomberg and covered widely at the time. HackerOne is the platform that pairs companies wanting their systems tested with ethical hackers who get paid bounties for what they find. A ranked leaderboard position on it is not a benchmark a vendor designed for itself. De Moor says the system went on to become "the number one hacker in the world" in August of that year. XBOW announced that worldwide ranking itself, so treat it as the vendor's claim rather than the independently reported one. He stresses the condition that makes either result interesting: "And I have to stress this is completely black box testing." Only the URL, nothing else.

Demonstrated, with the vendor's own framing. De Moor opens with a remote code execution vulnerability that XBOW found in Microsoft's Bing image search, which he calls "the very worst kind of vulnerability where you can run arbitrary code on the target system, complete takeover." Two details he attaches to it: "the only input it needed was the URL. Nothing else," and a cost of "$3,000 at list price. That's not what it cost us." Read that second number carefully, because it is easy to misread as a bounty. It is what he says finding the vulnerability would cost at XBOW's own price list. XBOW has published advisories for Microsoft findings, so the work exists. The framing of the price is a sales argument, and a good one, but it is a sales argument.

Extrapolated, and labeled as such by the speaker. XBOW topped the leaderboard using what de Moor calls an alloy of two frontier models, and the mechanism is genuinely interesting: "think of these attacks as a sequence of actions and at every step, you flip a coin to decide what model to ask." His claim is that "this is much better than either model separately," because the two models compensate for each other's mistakes, which he likens to pair programming. He then says that when the next frontier model shipped, "just extrapolating from its performance, it would have done at least three times better."

That last one is an extrapolation from benchmark performance, not a measured result, and he says so. Take it seriously as a direction. Refuse to repeat it as a fact. This distinction is the whole reason to read a vendor talk carefully rather than dismissing it: the leaderboard position is checkable, the multiplier is a forecast.

Why AI penetration testing changed the patch clock

The strongest claim in the talk is not about XBOW at all. It is about how long you have between a vulnerability becoming public and someone using it against you.

De Moor's version: back in 2018 the delay between a CVE being published and bad actors exploiting it in the wild ran to nearly two and a half years. Today, he says, "the number has gone negative." For most CVEs, exploitation is already happening before the CVE is published.

That is a big claim, so check it against a source with no product to sell. Mandiant, now part of Google Cloud, has published a running series measuring exactly this. Its numbers do not match de Moor's 2018 baseline, and the gap is instructive: Mandiant reports an average time-to-exploit of 63 days across 2018 and 2019, falling to five days by 2023. A CMU Software Engineering Institute analysis counts something different again, public exploit code rather than observed exploitation in the wild, and finds that only about 4 percent of CVEs ever get public exploit code within a year, though when one does appear the median delay is two days.

The datasets disagree because they are counting different events, so be precise about what is actually established. Mandiant does not report a negative average, and no public dataset we could find does. De Moor's "gone negative" is his own characterization, not a measured consensus, and a vendor CEO has an interest in the sharper version. What Mandiant does report is the number that carries his point anyway: in 2023, 70 percent of exploited vulnerabilities were exploited as zero-days, meaning before a patch was available, up from 62 percent across 2021 and 2022. That is the defensible claim, and it is close enough to be uncomfortable. For most of what actually gets exploited, the disclosure that would have warned you arrives after the attack.

The founder consequence is not subtle. If your dependency update policy is to patch whenever the quarterly upgrade comes around, you have not chosen a cadence. You have chosen to be exploited on the vulnerabilities that matter, because the disclosure that would have warned you now arrives after the attack. The same shift is visible from the defender's side. In an a16z conversation on AI and offensive security, Socket scans open source dependencies for supply chain attacks, and its founder and CEO Feross Aboukhadijeh describes frontier models causing "a massive reduction in the time between the vulnerability discovery and vulnerability exploitation," and draws the operational conclusion that the industry cannot keep requiring engineering teams to do large, manual version upgrades to stay current.

For a startup, that translates into one architectural decision worth making now: your dependency updates need to be routine and mostly automatic, or they will not happen at the speed the threat now moves. A patch process that requires a human to schedule it is a patch process that runs quarterly no matter what you intended.

The attacker takes the cheapest path, and it is not your zero day

This is the part the vendor pages leave out, and it is the part that should decide where a founder spends the next thousand dollars.

An autonomous attacker optimizes for cost like any other agent. Dylan Ayrey, co-founder and CEO of Truffle Security and the original author of the open source secret scanner TruffleHog, puts the economics plainly in that same conversation. His company recently found a leaked API key with administrative access to the Apache Foundation, and his point is what a model does when both paths are open: use the credential lying in the open, or "burn tokens and tokens and tokens" hunting for a zero day. Models are trained to reach the goal cheaply, so they take the credential. As he summarizes his own company's admittedly biased view, "a password laying around is a shorter path than going through a fancy zero day."

Ayrey also explains why models are good at this in the first place, and the explanation should retire the idea that it is emergent behavior nobody chose. "The interesting thing about cyber security in particular is the reward function is incredibly well defined. Get access to the data. Did it get access to the data? Reward the thing." Capture-the-flag problems are close to an ideal reinforcement learning target, which makes offensive security one of the most natural capabilities to train for. His framing of what changed: "The bar previously was just subject matter expertise and now the models have the subject matter expertise."

Two concrete numbers from that conversation. Working with Hugging Face to clean up credentials exposed in training datasets people had uploaded, Truffle found "about a quarter million live keys," some with direct supply chain implications, including one with push access to a foundational Linux library. Separately, Ayrey describes finding a single database credential that reached the personally identifiable information of roughly 3.6 percent of the world's population.

None of that is exotic. All of it is the boring failure: a secret that got somewhere public and stayed live.

The second cheap path is your dependencies. Aboukhadijeh's summary of the year is unambiguous: "2026 is the year of the software supply chain." He describes a self-propagating worm running through hundreds of npm packages, malware that he believes was largely model-generated, and a detail worth knowing if you run coding agents on developer laptops: attack payloads are increasingly prompts rather than binaries, which slide past endpoint tooling that has no idea a markdown file being read by an agent is an attack. His observation about the maintainers behind the packages you depend on is the uncomfortable one. Many are volunteers with no security team and no funding, and "there aren't resources to look for them" when it comes to the vulnerabilities in that code.

The most consequential recent example sits between the two paths. In the AI-assisted breach of Mexican government systems reported in February 2026, an operator used frontier models to compromise multiple agencies and exfiltrate roughly 150 gigabytes of data including tax and voter records. How the operator first got in has not been publicly reported, and it is worth resisting the urge to assume. What has been reported is what the models did once inside: writing the exploits, building the tooling, and automating the theft. They made the operator faster and far more productive. The reporting does not say they made the operator cleverer.

What an AI penetration test will not do for you

Given all of the above, here is the honest scope of the thing on page one of that search.

It will do: continuous black-box testing of the attack surface you point it at, at a cost per test low enough to run monthly rather than annually. Prioritization, which de Moor correctly identifies as the real deliverable: "You need to know whether the bugs are truly exploitable and what their impact is going to be." Proof of exploitability, which is the difference between a report with 400 findings and a report with the four that matter. And a document you can hand to the enterprise customer whose security questionnaire started this whole conversation.

It will not do: find the AWS key in your public GitHub repository, your CI logs, or a dataset someone on your team uploaded. Vet the dependency your engineer added last Tuesday. Patch anything. Tell you what data you hold or where it lives. Or notice that your former contractor's account is still active. Nor produce the certificate the enterprise buyer is really asking for, which is a different artifact on a different clock: AI compliance covers what those regimes actually require.

That is not a criticism of the category. It is a scoping statement, and it is the reason the order of operations matters. Running an autonomous pentest against your app before you have scanned your own repositories for secrets is buying the expensive test for the unlikely attack while leaving the likely one untested.

Security work also has a compounding relationship with the rest of your engineering. If a prompt injection or an agent misuse ever does land, the only record of what your system was actually instructed to do is whatever you stored, which is one more argument for the trace discipline we covered in LLM observability. And the pre-ship gate that keeps regressions out of production is a different job from the adversarial one described here, which is worth reading alongside AI testing in the AI coding era. If you want to see who is building in this space, our hub on AI for security tracks the Y Combinator companies working on it.

How long the AI penetration testing advantage lasts

De Moor closes with a call to action and a clock. Frontier labs, he argues, should stop debating whether to maximize the cyber capabilities of their models, because "we're in an arms race." Defenders should use the same tools offensively against their own systems. And there is a window: "We've got about 6 to 9 months to do this," after which he expects open-weight models to match today's leading code-analysis models, which is the point at which the capability stops costing money. His closing line is a joke with a real edge, that if you want a pleasant Thanksgiving dinner with your family, you should start fixing now.

Treat the specific timeline as a forecast from someone with an interest in urgency. Treat the structure of the argument as correct, because it does not depend on the date. Offensive capability that currently costs money to access will eventually cost nothing, and capability that runs on open weights cannot be recalled or rate-limited. The direction is not in dispute even if the month is.

The founder version is smaller and more actionable than the industry version. You are not going to out-invest this. What you can do is make sure the cheap attacks do not work against you, because a capable autonomous attacker will try those first, and they are the ones you can actually close in an afternoon. His broader plea applies to your company too: "We need every possible defense that we can get against these autonomous AI-powered attacks." At startup scale, most of those defenses are unglamorous.

One more, from the same a16z conversation and worth naming because it is arriving now rather than later: as agents get credentials of their own, the number of secrets in your company multiplies. Ayrey's assessment is that "the way agents interact with secrets right now is a wild west unsolved problem." If you are giving agents production access this quarter, decide how those credentials are issued, scoped, and revoked before you have thirty of them and no inventory.

What to do this week

1. Scan your own repositories, logs, and buckets for live secrets. Run an open source secret scanner across your git history, not just the current tree, and across CI logs and any dataset you have published. This is free, it takes an afternoon, and it addresses the path an autonomous attacker tries first.
2. Rotate anything it finds, and check whether it was used. A key found is not a key that was never used. Pull the access logs for each one before you close the ticket.
3. Turn dependency updates into a default, not a decision. Automated update pull requests with tests running against them. If a patch requires someone to schedule it, the time-to-exploit numbers say you will be late.
4. Write down where your data lives. One page: what personal or customer data you hold, which systems hold it, and who can read it. You cannot scope a penetration test, or an incident, without this, and it is the artifact every security questionnaire is really asking for.
5. Scope one AI-driven external test, and run it against staging first. Get written authorization, scope it by hostname and address range, and learn what an autonomous agent does to a system somewhere it cannot hurt you.
6. Decide your agent credential policy before you need one. How an agent gets a credential, what it is scoped to, how it is revoked. Do this while the answer is still one paragraph.

The pattern under all six is that security at startup scale is an operating decision about defaults and ownership, not a product you buy once a customer asks. That is the same kind of decision the AI Operating System for Startups is built around. For how it fits with the rest of the engineering picture, start with our pillar on AI for startups.

Sources

• Inside the Rise of Autonomous AI Hackers (Sequoia Capital), the AI Ascent talk by XBOW's Oege de Moor that this article distills.
• AI Is Learning to Hack. Faster Than We Expected. (a16z), the conversation with Truffle Security and Socket that supplied the defender's side: attacker economics, leaked credentials, and the software supply chain.
• Background on the people and companies named: Oege de Moor on LinkedIn, XBOW, and Semmle on Wikipedia; Dylan Ayrey on LinkedIn and Truffle Security; Feross Aboukhadijeh on LinkedIn and Socket.
• Bloomberg's report on XBOW topping the HackerOne US leaderboard in June 2025 (paywalled; the same milestone is covered free at CSO Online and TechRepublic), and XBOW's own security advisories for the Microsoft findings.
• Time-to-exploit data: Mandiant and Google Cloud's analysis of 2023 time-to-exploit trends for the 63-day 2018 to 2019 average, the fall to five days by 2023, and the 30:70 n-day to zero-day exploitation split, and the CMU Software Engineering Institute's historical analysis of exploit availability timelines for how rarely public exploit code appears at all.
• Reporting on the AI-assisted breach of Mexican government systems: the Los Angeles Times and SecurityWeek.