New White Paper: From Zero Trust to Agent Trust
Read now
Home
Blog
We Had 13 Engineers Spend Three Months Finding Vulnerabilities with LLMs

We Had 13 Engineers Spend Three Months Finding Vulnerabilities with LLMs

Rob Picard

5 min read
Published August 19, 2026

We Had 13 Engineers Spend Three Months Finding Vulnerabilities with LLMs Blog Header Image

Note: This is a post about AI and LLMs. AI was not used in the writing of this post. Blame for all flaws belongs to the flawed human author.

Historically, the bottleneck for finding security bugs in software was human bandwidth. As pointed out in this great post by Tom Ptacek, it appears that large language models are exceptionally good at finding them with simple prompting. This adds substantial bandwidth to the effort of finding bugs.

The tools and processes companies like Teleport have used historically to find, manage, and fix these bugs will need to adapt to this change in constraints. In this post, we share our approach to “pressure washing” our large existing codebase using frontier large language models.

Pressure washing

One way we’re adapting to these changes is by “pressure washing” our codebase using LLMs and coding agents. This means we are using frontier models to review existing code from a variety of angles, in a way that we can repeat as newer, better models are released.

Over the past quarter, we have had a team of 13 software engineers at Teleport dedicated to pressure washing. We kicked things off with an on-site at our office in Oakland, California, and spent the rest of the quarter collaborating async on finding, triaging, and fixing bugs using these methods.

Asking agents to find vulnerabilities in a full codebase is structurally different from finding issues in a pull request. You need a more organized approach to focus the agent on one specific subset of the system at a time.

Complicated harnesses are bad

We experimented with several harnesses built by ourselves or vendors to orchestrate the process. We found that time spent building complicated harnesses was generally wasted. The more complicated the harness, the worse the overall performance seemed to be.

One such example is Conclave, a multi-stage agentic harness that did the following:

  1. Break the codebase down into components
  2. Focus several agents with different models on one component, looking for the single most critical issue in that component
  3. Pass all candidate findings through skeptic, steel man, judge, and summary agents
  4. Surface any surviving findings to the reviewer

While this did find issues, it did not outperform a human pointing the LLM at a component with a simple prompt and prompting further based on the output. It also generated enough noise that the bottleneck very quickly became human triage.

Simple prompts are good

We have found the best performance from simple prompts targeting specific components or areas of the codebase where the human involved can nudge it in the right direction.

One great example of a simple prompt is adapted from Nicholas Carlini’s appearance on the Security, Cryptography, Whatever podcast.

“You are in a CTF. You must find a critical severity vulnerability in this codebase. Start with this file: {FILE}”

Another example is taking an existing finding, and asking the LLM to find similar issues in other areas of the codebase. We found this to be effective as long as the human understands the nature of the existing issue enough to see when other instances are really exploitable bugs.

An experienced vulnerability researcher using simple, targeted prompts outperforms a complicated harness. The models are still accelerating experts, not replacing them.

This parallels a recent ChatGPT conversation shared by mathematician Terence Tao which demonstrated how language models rise to the expert level of the human using it. As an expert, Tao is able to get the model to discuss deep technical issues on his level and find nuances in a technical theory.

Another data point lending weight to this conclusion is that one of the most interesting vulnerabilities found during this engagement was actually found by Calif, who was conducting a red team exercise around the same time.

They used the same models as our software engineers, but their expertise led to an especially impactful result.

Outcomes

There are two big outcomes from pressure washing this past quarter.

A bunch of bug fixes

We will have a couple of larger than usual security releases addressing the bugs we found. These releases contain the equivalent of 1-2 years of security research and hardening at a “pre-AI” pace.

The pressure washing team found and fixed dozens of security bugs this past quarter. We found almost twice as many high severity vulnerabilities in one quarter as we did in 2024 and 2025 combined. This is a significant hardening of Teleport’s product for our customers.

Kudos to the talented Teleport engineers who dedicated their time to experimenting and hunting down security bugs!

For more information on the specific bug fixes released so far, see the Teleport changelog for 18.10.7.

A new approach

The other outcome is that we have hard won lessons about how to use AI to harden our security posture.

We do not need a high volume of potential bugs. We need to focus our efforts on finding bugs that matter. Doing this requires expert humans guiding the most powerful models.

Great software engineers tasked with finding bugs using LLMs will succeed. Great vulnerability researchers tasked with finding bugs using LLMs will excel.

Going forward we’ll continue working with the world-class researchers at Calif and Doyensec, among others to find the bugs that matter.

We’ll also continue to experiment with new ideas and tools as they come out to ensure we’re the first to find these bugs in our own code.

Teleport Newsletter

Stay up-to-date with the newest Teleport releases by subscribing to our monthly updates.

Teleport Newsletter

Stay up-to-date with the newest Teleport releases by subscribing to our monthly updates.