The formula for the bill
"45%" is frightening on its own, but you cannot work with it. Let us work out what it means for a real team.
Suppose you merge 200 units of code a month that have a meaningful security surface: input handling, output rendering, database queries, logging. Of those, 60% are produced with an AI assistant. The 45% is a rate measured on generation tasks, and the arithmetic assumes that one such unit of code corresponds roughly to one generation task.
Units built with AI: 200 × 0.60 = 120
Of those vulnerable (45%): 120 × 0.45 = 54 / month
If review + static analysis together catch 80%
(a generous assumption):
Slips through: 54 × 0.20 = ~11 / month
Over a year: ~130
(Own calculation, assumptions above. The 45% comes from a longitudinal measurement across more than 150 models and 80 tasks.)
Eleven vulnerabilities slipping through per month. That is the bill — and it does not show up in the price of the tool.
But the most important part is not the multiplication. It is that the 45% is not what decides it; what decides it is which vulnerability class your code falls into. In the same measurement, parameterised queries come in at 82% safe and crypto at 86% — but XSS at 15%, and log injection at 13%. If you render HTML and write logs, you are on the bad side. If you work with a database, you are on the good one.
The centre of gravity of risk has moved
The best-known risk list in the field was refreshed in August 2026, and the change says more than the list itself.
Two movements stand out:
- Excessive agency climbed from sixth place to third.
- Improper output handling dropped from fifth to tenth.
So in the profession's view the centre of gravity of risk has moved from the model's output to the agent's permissions. The main question is no longer what the model writes — it is what it can actually get done with it.
Two things worth knowing about the list:
The years slip. The current edition came out in August 2026. The previous one, which everybody quotes as "the 2025 list", was actually produced in November 2024. If somebody cites "the 2025 list", there is a good chance they are quoting a two-year-old document.
And for the first time there is incident data behind it. In this edition the expert vote carried 75% of the weight, and the remaining 25% came from data on 6,639 real incidents taken from public vulnerability databases.
The framing sentence of the list is the best summary of the whole topic:
"Do not try to build a model that cannot be fooled. Build the system around it so that when it is fooled — and it will be — nothing important breaks."
Two cases that actually happened
Instead of theoretical risk, it is worth looking at two documented cases.
The file that took over
In the summer of 2025 a researcher reported a vulnerability in the AI extension of a popular development environment that is a textbook example.
The attack goes like this: an instruction placed in a source file, a web page, an issue or a tool response — possibly as invisible text — talks the assistant into rewriting the project's settings file and switching on automatic approval inside it. In the discoverer's words, that setting "disables all user confirmations, and from there we can run shell commands, browse, and so on".
From that point any command can be run on the developer's machine. And the reason it is called wormable is that the code written this way can carry the instruction onwards.
The vendor confirmed it and fixed it in August 2025. The lesson, though, has not expired: the text of a file sitting in a repo can also be an instruction.
When the agent became the weapon
In August 2025, malicious code made it into the installer of a large open source package family. It is the method that makes this the backbone of the article.
The malware called the installed AI command line tools themselves — with their permission-skipping flags — and had them find and read out secrets from the file system. It did not exploit a vulnerability in them. It used them, exactly as designed.
The tally: more than a thousand valid access tokens, dozens of cloud and package manager keys, roughly twenty thousand leaked files, and in the second wave more than 5,500 private repos turned public. The exposure window in the first phase was around eight hours.
This is the textbook case of excessive agency. An agent running on a developer machine can do more than make mistakes — it can also be a tool in somebody else's hands.
The clock that is already running
This is what makes the article timely, and it came into force in September 2026.
Under the EU regulation on cyber resilience, from 11 September 2026 manufacturers of products with digital elements have to report actively exploited vulnerabilities and severe incidents:
| Deadline | What is required |
|---|---|
| 24 hours | early warning, from the moment you become aware |
| 72 hours | full notification |
| 14 days | final report for an actively exploited vulnerability, after the fix becomes available |
| 1 month | final report for a severe incident, counted from the 72-hour notification |
Reporting goes through a single shared platform, as one submission. Open source software stewards are covered from 11 December 2027.
Important: this is a regulation, not a directive. It applies directly in every member state, with no room for national transposition and no separate national deadline. What the member state does have to designate is where the report goes and who the market surveillance authority is — and not everyone is at the same point on that. Open the one that applies to you:
Hungary — the designation is done, and so is the address
The report goes to the National Cyber Security Institute, which sits inside the Special Service for National Security and which the EU agency lists as the coordinator CSIRT. The reporting address for this regulation is a dedicated email address, not the general help desk.
The national implementation is in place too: parliament passed Act CXXXV of 2025 on 10 December 2025 and it was promulgated on 29 December. The act assigns the notifying authority and market surveillance authority roles to the Supervisory Authority for Regulated Activities — so neither to the data protection authority nor to the cyber security institute.
What matters about that for a small company is that the two roles are split: you report the incident to the cyber security institute, but you answer for product compliance to a different authority.
Spain — the reporting duty is running, the designation is not
The report goes to the emergency response team of the Spanish national cyber security institute, INCIBE-CERT, which is the coordinator CSIRT. That part works.
The national designating decree, however, was still a draft in September 2026. The text would assign the notifying authority role to the Centro Criptológico Nacional and market surveillance to the state secretariat for telecommunications and digital infrastructure; the Spanish competition authority gave its opinion on 13 May 2026, but nothing has appeared in the official gazette since.
Which means that in Spain the reporting obligation that started on 11 September 2026 is live while the market surveillance authority is not formally designated. That is not an exemption: the obligations of the regulation apply directly, it is only the domestic implementing side that is late.
The practical consequence of this is not legal compliance but readiness: you can report within twenty-four hours only if you know what is running on your side, in which version, and who is responsible for it.
The minimum defensive routine
1. THE AGENT SHOULD GET NO MORE THAN IT NEEDS.
This became the 3rd highest ranked risk. By default,
strict approval, no network, in a container or a VM
when the task is risky.
2. THE PERMISSION-SKIPPING FLAG IS A DECISION, NOT A COMFORT.
The documented attack used exactly those flags.
3. CHECK EVERY NEW IMPORT in the package registry,
lockfile and hash verification in the build.
4. OUTPUT ENCODING AND LOGGING GET THEIR OWN PASS.
15% and 13% safe rate. The gap is widest here.
5. SECRET SCANNING IN CI, not in code review.
No human will find that in a PR of several hundred lines.
6. WHATEVER IS IN THE REPO IS INPUT.
Issue text, comment, documentation, tool output - any of
them can carry an instruction. Do not assume text is data.
7. KNOW WHAT RUNS ON YOUR SIDE AND IN WHICH VERSION.
You can only report within 24 hours if you have this.
What not to believe about yourself
In a 2023 survey, 77% of 404 IT professionals thought AI tools improve the security of code.
In the same year, in a controlled experiment, the people using AI wrote less secure code — and were more likely to believe they had written secure code.
That experiment also had a side result which is the most practical advice on the whole subject: the participants who trusted the AI less, and spent more effort on wording their own request, left fewer vulnerabilities in the code.
Common misconceptions
- "Modern models write secure code now." Compilability has improved a great deal, the security rate has been essentially flat since 2023.
- "Bigger model, safer code." Model size has a very small effect on it.
- "The risk of AI code is theoretical." There are two documented cases: in one, the text of a file took control; in the other, installed agents were used for data theft.
- "Prompt injection is a chatbot problem." In the documented cases the carrier was a source file, an issue and a tool response.
- "The CRA will come later." The reporting obligations have been running since 11 September 2026, and this is a regulation — there is no transposition grace period.
What to take away
The security bill is not in the price of the tool, it is in the roughly eleven vulnerabilities slipping through every month — and in which vulnerability class you happen to work in. The centre of gravity of risk has moved from the model's output to the agent's permissions: the most important setting today is what the tool cannot do. And since September 2026 the reporting clock is ticking too.
The concrete steps of that review are what the going through generated code post lays out; and the separate attack surface opened by invented package names is the subject of the slopsquatting post, with the numbers.