You have probably sat in a version of this room. Four hours into the forensics, nobody has slept, and the thing the security lead keeps circling back to is that the code is not actually wrong: it does exactly what the ticket said, fetching the records for the requested account, paging them at fifty, returning JSON. Clean. Reviewed. Green pipeline, two approvals, shipped on a Thursday.
Then somebody reads the ticket again. Out loud. All the way through, and what is missing from it turns out not to be a line of code at all but a sentence in plain English that nobody ever typed: this endpoint must return only the records belonging to the authenticated caller. Not in the story. Not in the acceptance criteria. Not in the definition of done that has been pinned to the top of the board since 2023. The model did not break a security rule. It filled a silence, and it filled it with something that looked entirely reasonable to three separate humans.
Why do AI-coding security incidents keep getting framed as a model problem?
Because a model makes a much better villain than a missing sentence. Watch the coverage after any incident involving code an assistant wrote and the shape is consistent: the model hallucinated, the model was careless, the model should have known better, and then somewhere around paragraph nine there is a detail about a policy nobody configured. Wrong layer. That framing is not stupid, it is just aimed one storey too low, and it produces a remedy that cannot work, which is to wait patiently for a model that refuses to write insecure code.
The counting has finally started, at least, which is more than was true a year ago. Georgia Tech's Systems Software and Security Lab has been running a tracker since May 2025 that does something nobody else was doing: take a published vulnerability, follow its fixing commit back through Git history, and check whether the code that introduced it carries an AI tool's signature, a co-author tag or a bot email address. Slow, unglamorous work. It is also the first real measurement anyone has of how often this is happening in the wild, and the curve it produces over the first quarter of 2026 is steep enough to be uncomfortable reading.
6 → 15 → 35
New AI-introduced vulnerabilities confirmed in January, February and March 2026, traced commit by commit. March alone exceeded all of 2025 combined. A tracker covering roughly 50 AI coding tools had confirmed 74 cases by that point, 14 of them critical and 25 high severity, and the researcher behind it is blunt that this is a floor rather than a ceiling. Those are the figures as reported in March 2026; the count has kept climbing since.
Sources: Georgia Tech Systems Software and Security Lab, Bad Vibes: AI-Generated Code Is Vulnerable, Researchers Warn, for the 74 confirmed cases and the 14 critical and 25 high severity split; and Hanqing Zhao, the graduate research assistant behind the Vibe Security Radar, interviewed in Infosecurity Magazine on 26 March 2026, for the monthly 6, 15 and 35 figures, the May 2025 launch, the roughly 50 tools covered and the five to ten times estimate. Inputs are CVE.org, the National Vulnerability Database, the GitHub Advisory Database and OSV. Figures as reported in March 2026; the project's live dashboard at vibesecradar.com had reached 272 cataloged findings through 26 August 2026.
Take that number carefully, because the lab takes it carefully. Zhao says outright that the true figure is probably five to ten times higher, since most AI-assisted commits carry no metadata signature at all and a great many vulnerabilities never receive a public identifier of any kind. So it undercounts. On purpose. What it measures cleanly is the direction of travel, and that is the part that should change how you plan next quarter rather than how you feel about any particular vendor. The direction has not softened either: by the time the project's public dashboard was last updated, on 26 August 2026, it listed 272 cataloged findings rather than 74, and it had re-binned some of the earlier months as later confirmations landed, which is exactly what you would expect from a tracker that only counts a case once the evidence chain is complete.
What actually goes missing when nobody specifies a security requirement?
The boundary. Almost always the boundary, and it shows up in one of three shapes: who is allowed to read or write a given row, which inputs the system must refuse outright, and under what circumstances an authentication check may legitimately be skipped. Those are requirements. They are not implementation details, they are not something a security team bolts on in a later sprint, and they are the sort of thing a competent business analyst can write down in an afternoon provided somebody thinks to ask for them.
Here is the finding that changed my mind about the whole category, and I came into it expecting the opposite. A formal-verification study posted to arXiv in April 2026 pushed 3,500 code artifacts from seven widely deployed models through the Z3 satisfiability solver, producing mathematical witnesses rather than pattern matches, and among its three side experiments one is quietly devastating: asked to review code of the same kind, the models identify their own vulnerable output 78.7% of the time. They know. They generate it at 55.8% anyway, because generating and reviewing are two different tasks and only one of them ever gets asked the security question out loud.
4 points
How much adding explicit security instructions to the prompt moved the mean vulnerability rate, against a 55.8% baseline across 3,500 artifacts from seven models. The same models flagged their own vulnerable output 78.7% of the time when asked to review it instead of write it. Telling a model to be careful is not a requirement. It names no actor, no object and no boundary, so there is nothing for a person or a test to check it against.
Source: Dominik Blain and Maxime Noiseux, Broken by Default: A Formal Verification Study of Security Vulnerabilities in AI-Generated Code, arXiv:2604.05292, submitted 7 April 2026. 500 security-critical prompts across five CWE categories, verified with the Z3 SMT solver. Disclosure: the authors are affiliated with Cobalt AI, whose analysis pipeline the study uses, and the dataset is published for independent checking.
That same study ran a second experiment I genuinely expected to go the other way. Adding explicit security instructions to the prompt moved the mean vulnerability rate by four percentage points. Four. An instruction to write secure code is a mood rather than a specification, and the distance between those two things is the whole subject of this article: a requirement names the actor, the object and the boundary in a sentence something can be tested against, while "be careful" names nothing at all and therefore cannot fail.
How does an unstated requirement become a plausible-looking vulnerability?
By being plausible. That is the entire trick, and it explains why these gaps sail through review: code that fills a silence is not strange code, it is the most ordinary code in the repository, the thing a perfectly competent developer would also write if nobody had mentioned the rule to them either. A scanner sees a working query. A reviewer sees a ticket satisfied and moves on, because the review question is "does this do what was asked", and it does. Nobody sees the sentence that was never written, because an absence has no line number to comment on.
From the field
Moltbook is the cleanest public example of this I have found, and it is worth reading generously, because the people involved behaved well once they knew. The platform, an AI agent social network that went viral in late January 2026, was built with AI coding tools. On 31 January at 21:48 UTC, Wiz Research contacted the maintainer to report that its Supabase database was fully readable and writable by anyone: roughly 4.75 million records, including 1.5 million agent authentication tokens and 35,000 email addresses, with some private messages carrying third-party credentials. Now the important part. The publishable Supabase key sitting in client-side JavaScript was not the defect, because that key is designed to be public and functions as a project identifier. Access is supposed to be governed by Row Level Security policies on the database itself, and in Wiz's words, "this critical line of defense was missing." Nobody had written the sentence "a row is readable only by the agent that owns it" as a requirement, so nothing downstream had any reason to implement it. All tables were secured by 01:00 UTC on 1 February, roughly three hours after first contact, and Wiz states that all data it accessed during the research and fix verification was deleted.
Source: Wiz Research, Hacking Moltbook: AI Social Network Reveals 1.5M API Keys, with the disclosure timeline and remediation steps as published. Industry: consumer web application built with AI coding tools.
Notice how little of that is about the model. Almost none. Three lines of client code that are correct in every Supabase tutorial became a skeleton key in production, and the difference between the tutorial and the breach was not code quality at all, it was one unwritten access rule. The same shape shows up wherever a framework offers a safe default that has to be chosen: the platform does its job, the generated code does its job, and the requirement that was supposed to sit between them never existed in any artifact anybody could review.
What would specifying security requirements upstream have changed?
The question itself. Everything downstream follows from it, because "write this endpoint" and "write this endpoint, where a caller may read only rows whose owner matches the authenticated subject, unauthenticated callers get 401 with no body, and a malformed account identifier is rejected before it reaches the query" are two different jobs with two different acceptance criteria. You can write a failing test for the second one this afternoon. There is no test for "be secure", which is precisely why that four-point result stops being surprising once you sit with it.
Amazon arrived at a version of this conclusion in public, and handled it about as well as a company can. In March 2026 the Financial Times reported on an internal briefing describing a run of recent incidents with, in the company's own phrasing, a "high blast radius" and relating to "Gen-AI assisted changes", listing generative AI use "for which best practices and safeguards are not yet fully established" among the contributing factors. Not a better model. Junior and mid-level engineers now need a senior engineer's approval before AI-assisted code reaches production, alongside a ninety-day code safety reset. Read that as a requirements control rather than a trust control: it inserts somebody senior who has to state what the change is allowed to do, before it does it.
Try this one on your own backlog. Twenty minutes. The only rule is that you are not allowed to open the code, because the whole point is finding out whether the answer exists anywhere except inside the implementation. Pick three endpoints your team shipped this quarter with AI assistance, then answer three questions about each:
- Who is allowed to call this, and what happens to everybody else?
- Which inputs must it refuse, and what does refusal look like to the caller?
- Which named person confirmed those two answers before the work started?
If the third answer is nobody, then the first two are guesses that have happened to be right so far. No judgement intended. It is the predictable output of a process that used to catch these things by accident, through a developer pausing over an access rule and wandering down the hall to ask somebody who would know, and the pause is exactly what generation removed.
None of which is an argument for slowing down, and I would be a hypocrite to make one. Speed is fine. The defect is running at machine speed against a specification written for a slower process, one that quietly depended on human hesitation as its last line of defence, and the gate most teams still run checks whether the code matches the spec rather than whether the spec was complete. What has to replace the hesitation is the sentence itself, written before generation, specific enough that both a person and a test can check it. That is the work Specira does: five specialist agents interrogate your interviews, tickets and policies from deliberately different expert angles, and a Red Team Critic attacks what they produce, hunting for exactly the boundary nobody stated. I build it, so discount the pitch and judge the mechanism.
Key takeaway
An AI coding assistant cannot violate a security requirement that was never written as a requirement. It can only guess. And it guesses well: plausibly, consistently, and in code that passes review, which is exactly what makes the gap survive every control you have downstream. The fix is upstream and unglamorous. Write the access rule, the input boundary and the authentication exception as testable sentences before anything generates against them, attach a named person to each, and the model's default stops being the thing that decides.
What turns an assumed security rule into one the model cannot guess at?
Write it down. In a Specira session the Security Analyst's note lands under the lead answer, asking who is authorized, what gets logged, and what the system does when the check fails, while the person who knows the answer is still in the conversation. That note becomes a requirement with acceptance criteria and cited sources. Approval routing then decides who has to sign the security stage, and the export gate refuses to release the package until they have.
What you are looking at. The discovery note is the Security Analyst raising it in the moment, the requirement detail is where it becomes checkable, and the approval configuration is who has to sign before it ships.
Tell us the authorization rule your team has never written down. We will show you what it looks like as a requirement with a reviewer.
Book a DemoScreens are from a seeded Specira demo workspace; counts and scores are sample data.
What are the most common questions about AI-generated code and security requirements?
