In February 2026, a vibe-coded product called Moltbook went viral — and then went sideways. The founder proudly noted they'd written essentially none of the code themselves; an AI assistant scaffolded the whole thing. The problem wasn't the idea. It was the infrastructure the AI generated to support it: a misconfigured Supabase database, left wide open. Security firm Wiz found roughly 1.5 million auth tokens and 35,000 email addresses exposed to anyone who looked. (Wiz)

No zero-day. No sophisticated attacker. Just AI-scaffolded permissive defaults that nobody reviewed before they hit production.

That's the whole story of AI-generated code security in one incident: the failure mode isn't exotic, it's unreviewed. And it's happening at a scale that human review was never built to absorb.

This is systemic, not anecdotal

The numbers have gotten hard to wave away:

  • AI now generates roughly 46% of new code for active GitHub Copilot users, up from 27% in 2022 (GitHub). About 92% of developers use an AI coding assistant at least monthly (Stack Overflow 2025 Developer Survey).
  • Veracode found 45% of AI-generated code samples introduce an OWASP Top 10 vulnerability — with no improvement across testing cycles from 2025 into 2026 (Veracode). Other studies put the flaw rate as high as 62% (OX Security), and CodeRabbit's analysis of 470 real-world pull requests found AI-written code carries 2.74× more security vulnerabilities than human-written code (CodeRabbit).
  • It compounds with iteration: a peer-reviewed IEEE-ISTAS 2025 study saw a 37.6% increase in critical vulnerabilities after just five rounds of AI-assisted "refinement" — and the degradation held even when the model was explicitly asked to improve security (arXiv).
  • And the review buffer is shrinking exactly when you need it most: AI produces far more code and bundles it into ever-larger pull requests — the 1,000-line "mega-PR" has become routine in 2026, past the point where careful line-by-line human review scales.

So the question isn't whether AI writes insecure code. It demonstrably does, predictably, in recognizable patterns. The question is what catches it before it merges.

The recurring failure classes — and what catches each

AI-generated code fails in a handful of repeatable ways. Here's the spine of it, mapped to what a scanner should actually flag.

1. Classic injection, XSS, SSRF, broken access control. LLMs are trained on the internet's code, vulnerabilities and all, so they reproduce the OWASP Top 10 faithfully. Veracode found AI models fail to defend against XSS (CWE-80) in 86% of relevant samples (Veracode), and Georgetown's CSET found insecure output in 48–73% of samples across five models (CSET); a December 2025 Tenzai test saw all five leading AI coding agents introduce SSRF in the same URL-preview feature (Tenzai). PullGuard's core engine covers these with data-flow (taint) analysis that follows untrusted input across functions and files, plus a dedicated check for broken access control / missing authorization. It runs 44 analyzers in total — deep cross-file taint tracking in 7 languages, and broader insecure-pattern coverage across 67 languages and config formats.

2. Hallucinated and slopsquatted dependencies. This is the timeliest one. LLMs invent plausible-sounding package names that don't exist — and attackers register them. A USENIX Security 2025 study examined 2.23 million package references across 576,000 AI-generated code samples and found 19.7% pointed to a package that doesn't exist, with 43% of those hallucinated names recurring on every run — predictable enough to weaponize (USENIX Security 2025). PullGuard flags imports of packages that don't exist or aren't in your manifest, across npm and PyPI — the slopsquat target an npm install would happily fetch. Maps to OWASP LLM03: Supply Chain.

3. Secrets pasted straight into code — and into prompts. AI-assisted commits leak secrets at about 2× the human rate — 3.2% vs 1.5% (GitGuardian, State of Secrets Sprawl 2026). PullGuard catches hardcoded credentials, and — because secrets often get committed and then "removed" — it also scans git history, where the secret still lives. There's also a distinctly AI-era variant: secrets and PII piped into an LLM prompt, where they become provider-visible data. That's OWASP LLM02: Sensitive Information Disclosure, and here's a real finding from the scanner:

Rule: secret_in_llm_prompt — Remove the secret/PII from prompt content; secrets belong in the SDK auth config only.
// Flagged: the credential becomes provider-visible prompt data
const prompt = `Connect with key ${process.env.DB_API_KEY} and summarise`;
await openai.chat.completions.create({ messages: [{ role: "user", content: prompt }] });

// Fixed: the model never needs the credential — do the privileged work
// app-side and prompt with the RESULT
const rows = await db.query(summaryQuery);            // app holds the credential
await openai.chat.completions.create({
  messages: [{ role: "user", content: `Summarise: ${JSON.stringify(rows)}` }],
});

4. Insecure-by-default snippets. Ask an AI to "just make it work" and you get TLS verification switched off, debug mode left on, untrusted model files deserialized. PullGuard flags each of these — the shortcuts that pass a demo and fail an audit.

5. LLM- and agent-specific risks. As apps grow agents and tool-calls, the attack surface shifts. PullGuard maps to the new OWASP catalogs directly: prompt injection (LLM01), disabled AI safety guardrails, and unbounded agent loops — the excessive agency (LLM06) and agentic-goal-hijack class that OWASP's December 2025 Agentic Top 10 was written for. It also carries a composite AI-risk signal that flags code which is both AI-touched and security-relevant for a human's attention, and an AI-provenance check that surfaces AI-authorship markers as a machine-readable record — advisory evidence for emerging AI-transparency regimes like the EU AI Act, not a compliance certification.

6. The dependency-vuln firehose. AI floods projects with dependencies, and a raw CVE list is noise. PullGuard ranks known-CVE findings by real-world exploit likelihood — EPSS scores and the CISA KEV catalog of actively-exploited vulnerabilities — so "fix this today" rises above "technically a CVE." Georgia Tech's Vibe Security Radar tracked CVEs attributable to AI tools climbing 6 → 15 → 35 across the first quarter of 2026, and estimates the true count is 5–10× higher (Georgia Tech). Ranked triage is the only sane answer to that volume.

One honest caveat, since Moltbook opened this piece: the exact breach was a managed-database setting in a cloud dashboard, which lives outside the repo. PullGuard scans the infrastructure code you commit — Dockerfiles and Kubernetes manifests — for insecure defaults, and the missing-auth checks above catch the application-layer version of "wide open." The lesson generalizes even where one specific control doesn't.

You already run a scanner. It has an AI-shaped blind spot.

Here's the uncomfortable part. The SAST and SCA tools most teams already run — the Sonars and Snyks of the world — were built for human-written code, and they're genuinely good at it. But they were not built for the failure modes above. They don't know a plausible-looking import is a hallucinated package someone registered last week. They don't look for a credential flowing into an LLM prompt, a safety guardrail switched off, or an agent loop with no bound. Prompt injection and excessive agency aren't in their rulebooks — those OWASP categories didn't exist when those rulebooks were written.

So the most probable state of your pipeline today: a scanner diligently catching last decade's bugs and waving this decade's straight through. AI-era security is its own category, and it's the one your current tools leave open. That's the gap PullGuard was built to close — not as a bolt-on rule pack, but as the thing it does first.

The point: a guard at the moment code enters the repo

Here's what ties it together. AI doesn't just write more insecure code — it writes it faster than anyone can read it, and packages it into PRs too big to review by hand. You can't solve that with more human eyeballs, and banning AI assistants isn't realistic (or, given the productivity, desirable).

The answer is an automated guard at the exact moment untrusted code tries to enter the repo: a scan on every pull request, commenting inline and posting a status check, showing only what the change introduced rather than re-litigating the whole codebase. The AI writes the draft; the guard decides what's allowed to merge. And because AI-generated code is often your most sensitive, that guard should run inside your own CI — your code never has to leave your perimeter to be checked.

PullGuard didn't start as a standalone scanner — it came out of how I already work. I work in DevOps and site reliability for enterprise clients — incident response, hardening, keeping big Java/Kubernetes systems up — and in my spare time I build software almost entirely with AI agents, including a trading system run by a hierarchical network of autonomous ones. That project taught me the lesson this whole piece is about: autonomous AI needs hard guardrails — permission gates, kill switches, an audit agent watching the others, even a check that fails the build if safety code is tampered with. PullGuard turns that same discipline outward, onto AI-generated code in anyone's repo.

The fuller story of that trading system — and the night an AI agent ran one migration and deleted 44,409 records, then wrote its own apology — is here.

And the lineage is concrete, not just thematic: PullGuard began as the drift-detection layer inside the project that followed — the part that kept autonomously-generated code from wandering off-spec — which itself grew out of that autonomous trading system. PullGuard is that lineage, matured into a security scanner.

That's the shape of PullGuard: catch the AI-era risks other scanners miss, rank what's left by real exploitability so you fix what matters instead of drowning in CVEs, do it on every pull request before merge, and do all of it inside your own CI — your code never leaves your perimeter. For code an AI wrote and a human barely read, that combination is the difference between shipping with confidence and finding out the way Moltbook did.

This is the first in a series. The pieces ahead each take one class from above and go deep — injection & data-flow tracking, broken access control & authorization, the software supply chain, secrets & sensitive-data exposure, and the OWASP LLM & agentic risks. The pattern is always the same: name the failure, understand why an AI produces it, and put an automatic check in front of it.

Your AI is going to keep writing the code. The only open question is what's standing between prompt and production.