Your AI Coding Agent Has Your Credentials

For most of the last decade, the security question about developer tooling was whether the code it produced was safe. Through 2026, a different question has become more urgent: what happens when the tool itself can be instructed by a stranger?

AI coding agents read context in order to work. They read issue titles, pull request descriptions, code comments, README files and CI logs. Much of that content is written by people outside your organization — anyone who can open an issue on a public repository. When an agent cannot distinguish between content it was asked to analyze and instructions it was asked to follow, that outside text becomes a command. This is indirect prompt injection, and it is the first entry on the OWASP Top 10 for Large Language Model Applications for good reason.

The clearest public demonstration came in April 2026, in research published as Comment and Control. Researchers showed that crafted pull request titles, comments and issue bodies could hijack AI coding agents running inside GitHub Actions — including agents from several different vendors — leading to command execution and credentials written into Actions logs. The Cloud Security Alliance described it as the first public demonstration of a single injection technique working across multiple vendors' agents. In one reported case, a malicious pull request title caused a security review action to post its own API key as a comment. The agent was not compromised in any conventional sense. It did exactly what it believed it had been told to do.

February 2026 showed where this leads. In an incident referred to as Clinejection, a malicious GitHub issue title triggered a chain of vulnerabilities that ended in the unauthorized supply chain compromise of a published npm package belonging to an AI coding tool. The compromised package remained available for roughly eight hours. The initial input was a line of text that anyone could submit.

Separately, researchers at Orca Security demonstrated that an attacker could file an issue containing hidden instructions, and that when a maintainer later opened a development container from that issue, the agent would exfiltrate the repository access token with no approval prompt shown to the user.

What makes this class of problem difficult is that none of it is a vulnerability in the traditional sense. There is no buffer to overflow and no injection string to escape. The agent parsed text, formed an intention, and used the permissions it had been given. Patching the agent does not remove the underlying condition, because the underlying condition is that the agent holds credentials, has tools, and reads untrusted input.

That reframes the defense. The controls that work are the ones that limit what a hijacked agent can accomplish, not the ones that try to make hijacking impossible.

Scope the credentials. An agent running in CI should hold the narrowest token that lets it complete its task, with write permissions granted deliberately rather than inherited. A token with broad repository or organization scope should never be present in a job that processes untrusted input.

Separate untrusted input from the instruction path. Where an agent must analyze external content, that content should reach it as data with a clear boundary, not concatenated into the same context as its operating instructions.

Gate irreversible actions behind a human. Publishing a package, pushing to a protected branch, posting externally and modifying infrastructure should require an approval step that a hijacked agent cannot satisfy on its own.

Log what the agent did, not only what it said. Tool invocations, files touched and commands run are the record you will need, and they are often the only place an injection becomes visible after the fact.

Treat the agent as an identity. It authenticates, it holds permissions, and it acts on your behalf. Every control you would apply to a contractor with commit access applies here: review, least privilege, revocation.

None of this is exotic. It is the access control discipline that applies to any automated actor in a pipeline. What is new is that this particular actor can be persuaded, in plain English, by someone who has never been near your organization.