Agent instruction injection

How it works

AI coding agents and automation tools are designed to read natural-language input, GitHub issues, pull request titles, commit messages, support tickets, repository instruction files, and act on it. That design choice is also the vulnerability: any text the agent reads from a source it does not control becomes a candidate instruction, indistinguishable to the model from a legitimate directive typed by the operator running it. Greshake et al. named and demonstrated this class, indirect prompt injection, in February 2023, showing that content an LLM-powered application merely retrieves and processes, a webpage, a document, a search result, can carry instructions the model then follows as if the operator had typed them.

The CI variant of the same problem is more recent and more consequential, because the agent runs inside a pipeline or runner that also holds workflow credentials, deploy keys, API tokens, cloud access, giving untrusted text a path to execute with the runner's full privileges. Novee Security demonstrated this variant at Black Hat USA in August 2026 against the coding-agent repositories of Anthropic and Google: a GitHub issue opened by an account with no repository privileges was enough to reach workflow credentials on the CI runners behind Gemini CLI and Claude Code. Gemini CLI before version 0.39.1 and Claude Code through version 2.1.163 carried the specific flaws involved; both shipped fixes. OpenAI's Codex repository was affected through its workflow configuration and was addressed by separating CI jobs rather than through a version patch. The pattern, not any single flaw, is the lasting risk: pointing an agent at content from anyone on the internet, inside a process that also holds secrets, inverts the trust model CI was built on.

Why it works

The control assumption that fails is that CI runners are a trusted execution environment because only authorized people can trigger a build. That assumption held when triggers were pushes and pull requests from known contributors. It breaks once an agent reads content, an issue body, a title, a file, from anyone with no repository access at all, and treats that content as input to act on inside the same runner that holds credentials. Untrusted input has effectively become executable, and no amount of scoping the agent's own permissions helps if the runner it executes in was never separated from the one holding the secrets.

How to detect it

• CI runs triggered by unprivileged or anonymous-adjacent actors (issue creation, external pull requests) that access secrets or credentialed steps not normally reached by that trigger type.
• Agent or automation processes making outbound calls to destinations that do not appear anywhere in the repository's own configuration or documented integrations.
• Workflow runs where an agent's tool-call sequence diverges from the pattern established by its own prior legitimate runs on the same repository.

Be honest about the limits: agents are built to take varied, unpredictable action based on natural-language input, so anomaly detection against a fixed baseline is far weaker here than for a rule-based pipeline. A run that looks unusual may simply be the agent doing its job on an unusual ticket. This is a design and isolation problem more than a monitoring one; detection alone will not close the gap the architecture creates.

How to stop it

• Separate untrusted-input passes from credentialed passes so the job that reads an issue, comment, or external pull request never shares a runner with the job that holds deploy keys or API secrets.
• Run agents in read-only sandboxes without elevated privileges, and as the final step in a pipeline so no privileged process runs after them.
• Scope workload identity tokens to the single repository and action that needs them, rather than issuing a broad or org-wide credential to any process an agent might drive.
• Treat every source of text an agent reads as attacker-controlled, including repository instruction files, pull request titles, and commit messages, not only the obvious ticket body.
• Give every agent an owner, an expiry, and a place in access review, the same governance a human-facing service account would get. See agentic identity and what is non-human identity.

Seen in the wild

• Opening a GitHub issue was enough to reach CI secrets in Claude Code and Gemini CLI
• Agent identity just got a protocol, which is the easy half

Sources

• MITRE ATLAS: adversarial threats to AI systems
• Greshake et al., "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection" (2023)
• Agentic identity, glossary