---
title: "AI Coding Agents Beat SQL Injection. Authorization at Scale Is the New Failure Mode."
date: 2026-07-24
tags: ["security","vulnerabilities","claude-code","appsec","code-review","spec-driven-development"]
categories: ["AI Tools","Guides"]
summary: "A new Theori study built 28 apps with five frontier AI models and confirmed 434 exploitable vulnerabilities after deduplication and PoC testing. SQL injection and XSS were nearly absent — but resource-exhaustion bugs, hardcoded secrets, and authorization gaps that double in larger codebases (11% to 28%) are the new failure modes agentic coding tools haven't solved."
---


![AI Coding Agents Beat SQL Injection. Authorization at Scale Is the New Failure Mode.](/images/ai-coding-vulnerabilities-shifted-from-injection-to-authorization.png)

For the past two years, the standard line on AI-generated code security has been simple and grim: models write textbook OWASP vulnerabilities — SQL injection, XSS, log injection — at rates that would fail any first-year secure-coding course. A new study from application-security firm Theori, [reported by Help Net Security on July 23](https://www.helpnetsecurity.com/2026/07/23/report-ai-code-vulnerabilities/), suggests that story is now out of date. The bad news is what replaced it.

## What Theori actually tested

Theori's team built 28 applications using five frontier models split between Anthropic and OpenAI, across three distinct workflows: a greenfield app built from a detailed specification, a greenfield app thrown together from a casual prompt, and a brownfield rewrite of an aging PHP codebase (Gnuboard7) migrated to Laravel and React. Every app went through Theori's pentesting platform.

The raw scan returned 8,827 findings. That number is essentially meaningless on its own — automated scanners are notorious for duplicate and false-positive noise — so Theori's researchers collapsed duplicates and then built working proof-of-concept exploits for whatever survived. What was left: 434 vulnerabilities the team could actually stand behind, split 196 across the greenfield apps and 238 in the single brownfield rewrite.

That methodology matters. This isn't a vendor press release citing an unaudited percentage; it's a scan-then-verify pipeline that throws away anything that can't be exploited, which is a meaningfully higher bar than most "X% of AI code has vulnerabilities" studies clear.

## The good news: injection is disappearing

Here's the part worth sitting with. Theori's team went in expecting the classics — SQL injection, cross-site scripting, the bugs that fill every secure-coding tutorial. They barely showed up. Across five different models, the agents defaulted to prepared statements and ORM query builders on their own, and sanitized user input without being told to. That's a real, measurable improvement over the picture painted by [earlier 2026 research](/posts/ai-generated-code-security-crisis-92-percent-vulnerabilities/) — most notably ProjectDiscovery's spring survey, which found XSS in 86% of AI-generated web-facing code. Whatever training and RLHF work went into that gap, it's closing.

## The bad news: the failure moved, it didn't disappear

The 434 confirmed vulnerabilities didn't vanish — they clustered somewhere else entirely.

**Resource exhaustion and denial-of-service** was the single largest category: 93 of 434 confirmed findings (21%), almost entirely missing rate limits and request-volume controls. No model in the study appears to have added them without being explicitly asked.

**Authorization gaps — insecure direct object references, broken access control — got dramatically worse as the codebase grew.** In the smaller greenfield apps, IDOR-class flaws accounted for 11% of confirmed findings. In the larger brownfield rewrite, that number jumped to 28%. The pattern Theori describes is intuitive once you see it: a same-user ownership check on a single endpoint is easy for a model to get right in isolation. The same rule, replicated correctly across hundreds of endpoints in a real application, is where consistency breaks down.

**Secrets and debug artifacts caused a disproportionate share of the worst findings.** Of 23 critical-severity vulnerabilities, 11 were hardcoded or default secrets — often inherited silently from quick-start templates and framework scaffolding — and 6 were debug-mode configurations left enabled, which is effectively remote code execution with extra steps.

Theori CTO Andrew Wesie's framing, quoted in Help Net Security's coverage, is the cleanest summary: the vulnerability classes models still struggle with are the ones that "require system-level understanding" — behavior that spans the whole application rather than living in a single function. A related write-up on the same research put it even more directly: models "frequently optimize for the 'happy path' while overlooking exceptional conditions, runtime abuse scenarios and long-term operational resilience."

## Why this is actually an argument for specs, not against agents

That "happy path" framing is worth pausing on, because it's precisely the failure mode Spec-Driven Development exists to close. A rate limit, a cross-endpoint authorization policy, a rule about which environment variables are allowed to ship to production — none of these live in a single function a model can reason about locally. They're cross-cutting requirements. If nobody writes them down, an agent optimizing for "does this endpoint work" has no signal that it needs to check them, and Theori's numbers show exactly that gap: the vulnerability classes that survived are the ones with no local, single-file expression of correctness.

Theori's own three-workflow design — spec-driven build, casual-prompt build, and legacy rewrite — makes the same point implicitly, even though the published coverage doesn't break out per-workflow vulnerability counts. The categories that persisted regardless of workflow are exactly the categories a spec is supposed to force into the open before code gets written: "every endpoint must verify resource ownership," "all public endpoints have rate limits," "no default credentials ship to any environment." None of that requires a smarter model. It requires the requirement to exist somewhere the agent can read it — and then a review pass that checks the implementation against that requirement rather than just against "did it compile and pass the happy-path test."

This is also the practical case for treating agentic code review as a mandatory pipeline stage rather than an optional nicety. Claude Code's `/code-review`, which Anthropic moved to run as a background subagent in [v2.1.218](/posts/pichai-admits-gemini-coding-problem-q2-earnings/) rather than blocking the main session, and `sandbox.credentials`, which blocks agent commands from reading secret environment variables and credential files outright, are both aimed at exactly the categories Theori flagged: authorization consistency and secret exposure, not injection. That's not a coincidence — it's the toolchain catching up to where the actual risk moved.

## The practical takeaway

If your organization's AI-code security checklist still leads with "check for SQL injection," Theori's data says you're auditing for a problem that's substantially solved and missing the one that isn't. The review burden has shifted from input sanitization — which frontier models now handle by default — to three specific, boring, high-leverage checks: does every endpoint enforce the same authorization rule, does anything accept unbounded input without a rate limit, and did any default credential or debug flag survive from a template into a deployed environment. None of those show up in a unit test. All three show up if you write them into the spec and verify against it.

## Sources

- [The AI code vulnerabilities that grow with your app — Help Net Security, July 23, 2026](https://www.helpnetsecurity.com/2026/07/23/report-ai-code-vulnerabilities/)
- [Vibe-Coded Apps Riddled With Exploitable Security Flaws — SecurityWeek](https://www.securityweek.com/vibe-coded-apps-riddled-with-exploitable-security-flaws/)
- [What 434 AI-Generated Vulnerabilities Reveal About Secure Software Development — Cybersecurity News, July 22, 2026](https://cybersecuritynews.com/what-434-ai-generated-vulnerabilities-reveal-about-secure-software-development/)
- [92% of AI-Generated Codebases Have Critical Vulnerabilities — sdd.sh, previously covered](/posts/ai-generated-code-security-crisis-92-percent-vulnerabilities/)