Introducing LUCY

We built LUCY because of what frontier AI can now do. These models can read a large codebase, recognize weaknesses that conventional scanners miss, and chain several of them together into a working path to sensitive data or systems. What changes the calculation is scale: anyone can now point hundreds of AI agents at software at once, continuously and cheaply. Defenders cannot answer that with human review alone. Our response was to point the same technology at our own software first, deliberately and repeatedly, so those paths are found and closed before anyone else finds them.

Doing that well is harder than it sounds, because modern applications do not live in one place. A single system may span numerous code repositories, open-source libraries, and shared services. Most security tools examine one piece at a time, so the risks living in the connections between pieces are the least likely to be found.

What LUCY does

LUCY reviews an application the way it actually exists. It analyzes everything within a single review environment, including code across every repository involved, infrastructure and deployment definitions, architecture diagrams, threat models and operational context. This gives LUCY the full context of the application. It counts every file in scope before starting, and the review is not complete until the record shows each one was considered.

It divides that estate into units and examines each through four security lenses: access controls, secrets and cryptography, injection and data flow, and infrastructure and supply chain. Each unit-and-lens pairing forms an independent review lane, and about twenty run at once. Running AI agents in parallel is what lets each lane read narrowly and carefully while the whole review still finishes in hours, where depth and speed would otherwise trade against each other. It costs more than a single pass, and for software handling customer money that is an easy trade.

Because these models are non-deterministic, one pass is never enough. LUCY repeats passes until a unit goes quiet, meaning new passes stop finding new things, and estimates what it may still have missed using capture-recapture, the statistical method ecologists use to count fish in a lake. It also tests itself on every single run: before the review begins, synthetic defects are planted in a disposable copy, and the review has to find all of them blind.

Every serious finding is then challenged by an AI independent reviewer whose job is to disprove it. Verify or drop: claims that survive are kept, and claims that fail are kept too, alongside the evidence that killed them, because nothing is silently deleted. Survivors are ranked by how serious they are in context, since a weakness an attacker can reach from the internet outranks the same weakness behind three controls, and each carries a specific proposed fix so the receiving team starts from a concrete change.

Finally LUCY sweeps across the whole application, represented as a connected graph rather than a pile of files, which lets it see what individual lanes cannot: several moderate weaknesses in different repositories that together form one attack path. Lanes find evidence. Sweeps connect it.

A review is certified only when deterministic checks confirm all of it, and LUCY is built to keep working until they pass. When a check fails it does not lower the bar; it restarts stalled work on its own and runs further passes until the standard is met or a person stops it. Those checks are ordinary code rather than AI judgment, so an independent party can re-run them on the delivered evidence and reach the same verdict.

What we learned running it on ourselves

This is not an experiment. Across nine generations of development, LUCY and the systems preceding it have reviewed our estate repeatedly, covering tens of millions of lines of code, many of them several times over as the system improved.

Nearly every capability described above exists because an earlier generation failed in a way we could observe: early versions produced confident finding tables with no evidence behind them, so we required proof for every claim, and we later learned a review can be rigorous about what it reports and still miss whole regions of an application, so we began measuring coverage. These capabilities make LUCY more effective across large complex code bases.

Why this matters: how do you trust an AI review?

AI is about to do a great deal of security review work across every industry that runs software. Whether to use it is largely settled. How anyone will know whether a given review was any good is not.

An AI security review arrives as a clean, confident, well-formatted report. A review that examined every file and a review that quietly skipped a third of them produce documents that look the same. Traditional scanners fail predictably, missing what falls outside known patterns, but AI review is different in kind because its coverage and reasoning vary from run to run. That variability is what makes it powerful and exactly why it needs measurement traditional tools never required. An AI security review should be expected to report on its own thoroughness, in evidence a third party can re-check, and that should become ordinary rather than a point of difference.

Why we’re open-sourcing it

LUCY was created through Fifth Third's work with frontier AI. We are releasing LUCY for the same reason we built it. Software supply chains are shared, and so are the weaknesses in them, so a technique that helps one security team is worth more in the open than held closely. Nothing about LUCY is specific to banking; any organization with software worth protecting can use it. If AI can be used at scale to find weaknesses in software, it should be used at scale to fix them first, and that is a better outcome for everyone.

Get LUCY

LUCY is available on GitHub as a working system and a methodology — for anyone to inspect, run, challenge, and improve. GitHub - Fifth-Third-Bank/lucy