AI Coding Agent Security Vulnerabilities: How Attackers Trick Your AI Assistant

What are AI coding agent security vulnerabilities?

They are ways an attacker can turn an AI coding assistant against the person or team using it. The assistant reads text, decides what to do, and then acts: it runs commands, edits files, installs packages, or posts to GitHub. If an attacker can control any of the text it reads, they may be able to steer those actions.

The OWASP Gen AI Security Project publishes a list of the main risks for apps built on large language models (LLMs), the technology behind these assistants. Its 2025 list puts prompt injection first ^[1]. A second entry, excessive agency, covers what happens when an AI system has more power than its job needs ^[2]. The two real cases below combine both ^[3][5].

How does prompt injection trick a coding agent?

Prompt injection means hiding instructions inside content the AI will read. OWASP separates direct injection, where the user types the instructions, from indirect injection, where they arrive from outside sources such as websites or files ^[1]. Coding agents read a lot of outside text: README files, code comments, issue threads, pull request titles (a pull request is a proposed code change) and web pages.

The hidden text does not have to look like anything to a human. OWASP notes that injected prompts do not need to be human-visible or readable, as long as the model parses them ^[1]. A comment buried in a file, or text a browser would never show, can still reach the model.

OWASP is also blunt about the limits of defenses. Because of how these models work, it says, it is unclear whether any fool-proof prevention exists ^[1]. That is why the advice below focuses on limiting damage, not on blocking every trick.

What happened in the "Comment and Control" attack?

In April 2026, security researcher Aonan Guan, working with Johns Hopkins University researchers Zhengyu Liu and Gavin Zhong, showed one injection pattern working against three agents ^[3]. The targets were Anthropic's Claude Code Security Review, Google's Gemini CLI Action and GitHub Copilot Agent, all running inside GitHub Actions, the automation system that runs jobs on a repository ^[3].

The attack text went into ordinary GitHub fields: a pull request title, an issue body or a comment ^[3]. With Claude Code Security Review, a crafted pull request title led the agent to run commands and reveal credentials (login secrets) in its report or in the job log ^[3].

Gemini CLI Action fell to crafted issue comments that got past its safety rules and exposed a full API key, a password that lets software use a paid service ^[3]. The Copilot version hid its payload inside an HTML comment, which does not show on the page ^[3].

The workflows started the agent automatically, so the victim did not have to click anything. Copilot was the exception, because someone had to assign the issue to it first ^[3].

All three vendors confirmed the findings. Anthropic rated the issue critical, and GitHub classified it as a known architectural limitation ^[3].

In his write-up, Guan said the prompt injection "is not a bug; it is context that the agent is designed to process" ^[3]. The agents had powerful tools and secrets in the same place where they read untrusted text ^[3].

Why is giving an agent too much power dangerous?

An agent that can only read files can leak what it reads. An agent that can also run shell commands, push code and use API keys can do far more damage when it is tricked. OWASP calls this excessive agency and lists three usual causes: too much functionality, too many permissions and too much autonomy ^[2].

OWASP's examples map closely to coding agents. One is a tool meant to run a single shell command that fails to block other commands ^[2]. Another is an extension that deletes files without asking the user first ^[2]. The trigger does not even have to be an attacker, since OWASP lists a model's own hallucinations as one common trigger alongside prompt injection ^[2].

How did a GitHub issue title lead to a hijacked npm release?

Cline makes an AI coding assistant for VS Code, JetBrains and the command line ^[4]. In December 2025, its team added a GitHub Actions workflow that used Anthropic's claude-code-action to sort incoming issues automatically, and any GitHub user could trigger it by opening an issue ^[5]. According to Cline's post-mortem, that setup created a prompt injection hole: an attacker could write an issue title with instructions that tricked the agent into running code ^[5].

GitHub Actions keeps a shared store of files, called a cache, to speed up jobs. According to the post-mortem, an attacker could slip bad files into it, and the nightly job that publishes new Cline versions would then load them ^[5]. That job had access to the secrets used to publish Cline's software. Security researcher Adnan Khan reported the flaw on January 1, 2026, and it was not addressed until he disclosed it publicly on February 9 ^[5].

On February 17, 2026, at 3:26 AM Pacific time, someone used a compromised publishing token for npm, the public registry for JavaScript packages, to release an unauthorized version, cline@2.3.0 ^[4]. The only change was a script that also installed another package, OpenClaw, globally on any machine that installed this version ^[4]. Cline's advisory describes OpenClaw as a legitimate project that is not malicious, but its installation was not authorized ^[4].

The bad version was out for about eight hours, and Cline's VS Code extension and JetBrains plugin were not affected ^[4].

Cline's own write-up admits one more mistake. During the response, the team deleted the wrong token, and the exposed one stayed active ^[5]. Since then, the company has removed its AI triage workflows and says any future automation will be read-only with no shell access ^[5].

Can an AI agent install a fake package?

Yes, and this risk needs no attacker inside the conversation. AI models sometimes recommend software packages that do not exist. If an attacker registers one of those made-up names on a public registry, a developer who trusts the suggestion could install the attacker's code. The researchers call this a new kind of package confusion attack on the software supply chain ^[6].

Researchers including Joseph Spracklen measured how often this happens across 576,000 code samples from 16 popular code-writing models, in Python and JavaScript ^[6]. On average, at least 5.2% of the packages that commercial models suggested did not exist, and the figure was 21.7% for open-source models ^[6]. Across all samples, they found 205,474 unique made-up package names ^[6].

How can you use AI coding agents more safely?

You do not have to stop using these tools. The safer approach is to assume that anything the agent reads could contain instructions, and to limit what it can do about them.

• Keep approvals on for risky actions. OWASP recommends human approval for high-impact actions ^[1][2]. If your agent asks before running commands or pushing code, leave that prompt on.
• Give it only the access it needs. OWASP's advice is to limit an agent's tools, functions and permissions to the minimum the task requires ^[2]. A review bot does not need to publish releases.
• Keep secrets away from untrusted input. The Comment and Control and Cline cases both put real credentials within reach of an agent that read public text ^[3][5].
• Treat outside content as untrusted. OWASP advises separating and clearly marking external content so it has less influence ^[1]. Be careful when you point an agent at an unfamiliar repository or web page.
• Check package names before installing. Look up any unfamiliar package the agent suggests on its official registry page before you run the install command.

If you run an AI agent in GitHub Actions, check today which events can trigger it and which secrets that job can read. In both cases above, an agent that anyone could trigger sat next to secrets it did not need ^[3][5].