How do you security-audit a codebase full of AI slop?

The defect profile changed shape

The first thing to get straight is that this is not a slop problem. "AI slop" implies low quality, and on precisely the axes that word suggests — carelessness, obvious errors, the thing you spot on the first read — assisted code measurably improved. It is not worse. It is wrong in different places, and the places are ones your existing tooling does not look.

That distinction decides what you go looking for, which is why it is worth labouring. Almost every tool that has grown up around the word attacks tidiness: near-duplicate helpers, pattern drift between files, hollow tests, ceremonial comments, the de-slop pass. All of that is real, and none of it is what gets you breached. The security half of the problem is a different list with a different shape, and it is the one nobody is selling.

Apiiro tracked more than 7,000 developers across 62,000 repositories and found that assisted developers shipped three to four times the commits — while syntax errors in their code fell 76% and logic bugs fell 60%.[1] Both of those are real improvements, and both are improvements in the class of defect a compiler or a linter already caught for free.

What went up were the ones nothing catches automatically: architectural design flaws rose 153%, and privilege-escalation paths rose 322%.

This is the whole problem in one picture. A privilege-escalation path is not a bad line of code. It is a correct line of code in a place where a check should have been and wasn't. Every individual statement reviews clean.

It also is not a problem the models are quietly fixing. Veracode has run the same benchmark across more than 150 models: given a task with no explicit security instruction, 45% of generated samples failed the security test, which is where the number sat two years earlier. Java came out worst, passing 29% of the time.[2]

The per-weakness breakdown is the useful part of that study. SQL injection passed 82% of the time and weak cryptography 86% — the famous ones, the ones with a canonical fix in the training data. Cross-site scripting passed 15% of the time and log injection 13%. The model has learned the flaws that have blog posts, not the flaws that have consequences.

And nobody is reading it

The second half of the problem is that the review process absorbing this code is the same one you had in 2023.

Faros AI published two years of telemetry from 22,000 developers on roughly 4,000 teams. Throughput went up — 33.7% more tasks per developer, 66% more epics. So did everything downstream: bugs per developer up 54%, incidents per pull request up 242.7%, code churn up 861%, median time in review up 441.5%.[3] And the release valve: pull requests merged with no review at all, human or automated, up 31.3%.

LinearB's benchmark across 8.1 million pull requests says the same thing from the other side. AI-assisted pull requests run 408 lines at the 75th percentile against 157 for unassisted ones, wait 16 hours before a reviewer opens them against roughly 200 minutes, and merge within 30 days 32.7% of the time against 84.4%.[4]

Read those two together and the picture is not "AI writes insecure code." It is that the volume of code arriving now exceeds the capacity of the process that was supposed to catch what is wrong with it, and the defects getting through are specifically the ones that process was the only defence against.

An audit is what you do when that has already been true for a year.

The four passes

01 — Authorisation boundaries

Enumerate every route, handler, queue consumer and scheduled job, and answer one question per entry: who is allowed to invoke this, and where is that enforced? Not "is there auth middleware" — which identity, checked where, on which object.

This is where generated code is weakest, because the prompt almost never contains the authorisation model. The model writes the path that was asked for and infers the rest from surrounding code, which works exactly until the surrounding code was also generated by inference.

The output of this pass is a table, and the useful column is the one marked "nowhere".

02 — Credentials and machine identity

GitGuardian counted 28.65 million new hardcoded secrets in public GitHub commits during 2025, up 34% year on year, with AI-service credentials the fastest-growing category at +81%. Commits made with coding-assistant help leaked secrets at roughly twice the baseline rate — 3.2% against 1.5%. And of the secrets they confirmed valid back in 2022, 64% were still live in January 2026.[5]

Two things to pull out of that. The first is that leaked is not the same as revoked, and most organisations have no process that turns one into the other. The second is that rotation is the easy half; the hard half is scope. A key that leaks is an incident. A key that leaks and was provisioned with administrative rights because narrowing it would have taken an afternoon is an outage with a press release attached.

So this pass has two lists: what is exposed, and what each machine identity is permitted to do if it is. The second list is usually longer and always more surprising.

03 — Dependency provenance

Models invent packages. Across 576,000 generated code samples, 19.7% of the 2.23 million package references were hallucinations — and when researchers re-ran the prompts that produced a fake name ten times each, 43% produced the same fake name every time.[6]

That reproducibility is the attack. A name a model reliably invents is a name someone can register and wait on, which is why the technique got its own word: slopsquatting. Open-weight models hallucinated at 21.7% on average against 5.2% for commercial ones, so the exposure varies with what your team runs locally.

The pass is mechanical and worth automating once: reconcile every import in the tree against the lockfile, and every lockfile entry against its registry record — first publication date, maintainer history, repository link that actually resolves. A package with a plausible name, 200 weekly downloads and a first release three weeks after your feature branch opened is the whole finding.

04 — Tool and agent surface

If anything in the codebase runs as an agent — an MCP server, a tool-calling loop, a CI bot with a token — this pass is the one that matters most, because it is the only place where a text-level defect becomes an executed action.

The Cloud Security Alliance's scans of the public MCP ecosystem found 43% of tested servers vulnerable to command injection and 82% to path traversal, with around 5.5% of nearly 1,900 servers carrying instructions embedded in tool descriptions — tool poisoning, where the payload is in the metadata the model reads and trusts.[7]

What to establish, per agent: the exhaustive list of tools it can reach, what each tool can do at its most destructive, whose text ends up inside its context window, and what happens when that text says something the operator didn't. Then cut the list until a successful injection is survivable. That is the only control here that generalises, because prompt-level defences are probabilistic and permission boundaries are not.

What comes out of it

A ranked list of findings with a reproduction for each, a branch containing the fixes that are cheap and unambiguous, and — the part that decides whether any of this holds — a written rule per finding class that stops it recurring: the CI check, the lint rule, the scoped token policy, the tool allowlist.

An audit that ends in a PDF has documented a moment. The codebase will have moved by the time you finish reading it.

What to skip

• A second SAST vendor. You are not missing these findings because your scanner is bad. You are missing them because they are not patterns.
• Banning the assistants. Throughput went up for a reason and nobody is giving it back. The 2026 data says the fix is review and permission capacity, not abstinence.
• Classifying which code is AI-written. It changes nothing about the fix.
• Boiling the ocean. Take the three workflows where a wrong answer costs real money and audit those properly. Whole-codebase coverage, at this volume, is a way of finishing late.

If you want the same reasoning applied to your own setup before committing to anything, the readiness audit is seven questions and returns a costed plan, and what we build explains where the review gates go.