TL;DR
What ENISE 2026 taught us about AI coding agent security
AI already writes your code. Deciding what reaches production is still up to you.
- One sentence was enough: a prompt hidden in a GitHub issue title led an AI triage agent to start a chain that ended in an unauthorized release of Cline, a coding assistant with more than five million users.
- No CVE was involved: the attack exploited five missing controls, not a classic vulnerability, so traditional scanners had nothing to flag.
- The bottleneck has moved: AI writes code and finds vulnerabilities fast. Integrating code safely and validating which findings are real is the hard part now.
- Coding agents are part of your supply chain: attackers target whatever writes your code: invented package names, poisoned dependencies, even the AI assistants on a developer's laptop.
The first step: answer four questions. Which agents act in your development, what they can bring in, what your pipelines can execute, and which findings you can actually validate.
At ENISE 2026 in León, our CEO Jesús Cuadrado opened his talk on AI coding agent security with a story, not a slide of statistics. Here’s what he told the room, and the four questions he left every CISO with.
One sentence was enough
Earlier this year, a security researcher showed that you could publish a fake version of a coding assistant used by millions of developers without an exploit, a zero-day, or a stolen password. All it took was a sentence in the title of a GitHub issue.
The tool was Cline, a popular open-source coding assistant. Like many projects today, its team had automated part of their work with AI: an agent read every new GitHub issue, classified it, and replied. To do its job, that agent had terminal access, and it ran on issues opened by anyone on the internet. Researcher Adnan Khan named the attack chain “Clinejection”, and Simon Willison has a clear summary of how it worked.
The chain broke in five places:
- External text became instructions. The issue title went straight into the agent’s prompt, so a request to install a tool looked like a command.
- The agent had more power than it needed. It was there to triage issues, but it could run commands, so it did.
- Triage and release shared a cache. The installed tool poisoned the CI cache, and the release workflow inherited it.
- Releases used a long-lived token. With the cache poisoned, the npm publishing token was within reach.
- No one approved the release. Nothing required a human to verify a version before it shipped.
Weeks later, someone exploited it for real and published an unauthorized version, cline@2.3.0. It stayed online for about eight hours and was installed around four thousand times. This time, the payload only installed another AI agent. It could have been a credential stealer or ransomware.
Notice what wasn’t there: no SQL injection, no CVE, nothing a traditional scanner would flag. So who decided that version could ship?
Nobody.
Five missing controls, and what closes each one
Every link in the Clinejection chain was a control that wasn't there. None of them required a CVE to exploit.
| Link in the chain | What was missing | The control that closes it |
|---|---|---|
| 1. Issue title | Untrusted text went straight into the agent's prompt | Treat all external input as untrusted, and keep it out of agent instructions |
| 2. Triage agent | A triage agent could run any command | Least privilege: give each agent only the tools its task needs |
| 3. Shared cache | Triage and release workflows used the same cache key | Isolate workflows and review pipeline configuration as code |
| 4. npm token | Releases relied on a long-lived publishing token | Short-lived, scoped credentials for publishing |
| 5. Release | No human approval or verification before publishing | Required approval and signed provenance for every release |
Writing code is no longer the bottleneck
Cline isn’t an outlier. It’s a preview. AI coding agents now write, install, and commit code at a pace no review process was designed for, and even AI labs report integrating changes faster than their own tooling can handle.
The bottleneck has moved. Writing code is cheap. Integrating it safely is not.
Finding vulnerabilities is cheap. Knowing which ones are real isn’t.
AI is also very good at finding vulnerabilities. What it can’t do on its own is tell you which ones are real.
The maintainers of curl, the library that runs on billions of devices, made this painfully visible. Most of the security reports they received weren’t real vulnerabilities, yet each one tied up members of a small volunteer team for hours. In January 2026, curl ended its bug bounty program, citing the flood of low-quality, AI-generated reports.
The same capability, AI-powered discovery, can produce hundreds of real findings or an avalanche of noise. The difference is who validates them and what that costs.
Your coding agent is now part of your supply chain
Attackers have drawn the logical conclusion: if agents write the code, why attack the code? Attack whoever writes it.
- Slopsquatting. Research on AI-generated code has found that models regularly recommend packages that don’t exist, often repeating the same invented names. An attacker only has to register one and wait.
- AI assistants turned against their owners. In the s1ngularity attack on the popular Nx build tool, the malware looked for AI coding assistants on the developer’s machine and asked them to find secrets: .env files, SSH keys, cloud tokens. The victim’s own AI did the attacker’s work.
The attack surface is no longer just your code. It’s everything that writes code for you. Many of these risks are now mapped in the OWASP Top 10 for LLM Applications and in the OWASP Top 10 for Agentic Applications, which we explain in our guide to the OWASP Agentic AI Top 10.
AI coding agent security: four questions every CISO should be able to answer
Jesús turned all of this into four questions. Try answering them for your own organization:
- Which agents and models are acting in our development today? Not the ones you approved: the ones that are there. IDE assistants, GitHub bots, agents someone set up to save time.
- What can they bring into our software? Invented packages, bait dependencies, IDE extensions, MCP servers, models downloaded from anywhere.
- What can our pipelines execute, and with which permissions? In Cline, a shared cache was enough to reach the publishing token.
- Of everything we’re told, which findings can we actually validate?
The fourth question matters more than it looks: you can’t rely on an agent’s own summary of what it did. You need independent evidence.
How does Xygeni answer them?
See what’s there. Xygeni AI Security builds an inventory of the models, agents, MCP servers, and AI coding tools in your repositories, with risks mapped to the OWASP Top 10 for LLM Applications. You can’t govern what you don’t know exists.
Stop what shouldn’t get in. Malware Early Warning detects malicious packages before a signature exists, and it’s included in our free plan. Xygeni Shield blocks malicious packages on developer workstations before they install and enforces a minimum age for packages, IDE extensions, and plugins, closing the window that these attacks rely on.
Protect the pipeline. CI/CD Security checks workflows, permissions, and secrets, and Build Security adds signed SLSA attestations, so you can prove that what you published is what you built. That’s exactly what failed in Cline.
Validate with evidence, not opinions. This is where AI promises the most and gets it wrong most often. A result that changes every time you run it can’t serve as evidence for an auditor or as a gate in a pipeline. So at Xygeni, AI doesn’t decide. In AI Pentesting, an LLM plans the attack the way a pentester would, but a deterministic oracle decides whether it worked, from a real and safe signal. Each verdict is exploitable, not exploitable or inconclusive, and each comes with a re-runnable proof of concept you can show your auditor or your board.
AI proposes. A deterministic engine decides. You keep the evidence.
The decision is still yours
Jesús closed where he began. A version of Cline shipped without anyone authorizing it, not because the team was careless, but because nobody had asked the right questions in time. That’s what AI coding agent security comes down to: asking those questions before an agent ships something for you.
AI already writes your code. Deciding what reaches production is still up to you.
So, which of the four questions can’t you answer today?
We spent three days at stand 62 talking with security and development teams about exactly these questions. Thanks to everyone who stopped by.
The Xygeni team at ENISE 2026, left to right: Jesús Cuadrado, Marcos Martin, and Agustín Sánchez Fonseca.
Want to see how Xygeni answers them in your environment? Start free or book a demo.
FAQs
What is AI coding agent security?
AI coding agent security is the practice of controlling what AI coding assistants and agents can see, install, execute, and publish in your software development lifecycle. It covers the agents themselves, the components they bring in, the pipelines they can trigger and the evidence you need to trust their output.
What was the Clinejection attack?
Clinejection was an attack chain against the Cline repository in which a prompt hidden in a GitHub issue title tricked an AI triage agent into running commands. Through cache poisoning, the attacker reached an npm publishing token and released an unauthorized version of Cline that was installed around four thousand times.
What is slopsquatting?
Slopsquatting is a supply chain attack in which an attacker registers package names that AI models tend to invent. When a developer or coding agent installs the hallucinated package, they get the attacker’s code instead.
Can AI validate security findings on its own?
Not reliably. AI can find and explain vulnerabilities, but its output can change between runs, which makes it weak as evidence. A safer approach is to let AI propose, and a deterministic engine decide, so the same input always produces the same, verifiable result.
