PROMPT INJECTION LANDS ON AI CODING AGENTS WIRED INTO GITHUB ACTIONS. KEYS LEAK. VENDORS STAY QUIET.

Security researchers prompt-injected AI coding agents from Anthropic, Google, and Microsoft integrated into GitHub Actions and walked out with API keys and access tokens. The vendors paid bug bounties. None of the three issued public warnings to the users already running those agents in production CI. Your pipeline’s autopilot is now the attack surface.

What happened

Per the report, researchers demonstrated that AI coding agents wired into GitHub Actions workflows can be steered by prompt injection to exfiltrate secrets the agent has access to — API keys, access tokens, anything the runner can read. The flaws spanned agents from three different vendors: Anthropic, Google, and Microsoft.

The researchers collected bounties. The vendors patched. Users running those agents in their own CI were not told.

Why “patched and quiet” is the wrong posture

Three things worth stating plainly.

1. The attack surface is the prompt, not the pipeline. Traditional CI security thinks about runners, secrets scopes, and branch-protection rules. An AI agent in the loop collapses all of that. The agent reads a file, reads a PR description, reads a comment, reads an issue. Anything an attacker can write into those is an instruction the agent might follow.
2. “Bug bounty paid” does not equal “users are safe.” A private disclosure plus a silent patch leaves every customer running a pinned action version on the vulnerable release. If you pinned your agent version for reproducibility, you may still be exploitable.
3. Three vendors, same class of bug. When Anthropic, Google, and Microsoft all shipped agents with the same failure mode, it is not a one-off. It is a category default. The category default is: agents in CI are not sandboxed from the secrets CI already holds.

The shape of the exploit

The source does not publish the attack chain. The shape is obvious enough:

• The agent runs in a GitHub Actions workflow with access to repo secrets.
• A PR, issue, comment, or file in the repo contains attacker-controlled text.
• The agent reads that text as part of its task.
• The text includes instructions that cause the agent to emit the secret — via a commit, a comment, an HTTP request to an attacker-controlled URL, or a log line that the attacker can read from the public workflow output.

You do not need a zero-day. You need a pull request.

What this means if you ship AI agents in CI

• Assume the agent will be prompt-injected. Treat the agent like untrusted code. It is reading untrusted input; it will act on some of it.
• Do not hand the agent full secret scope. Give it only the minimum scope for the job. If it only needs to comment on PRs, it should not see your deployment tokens.
• Log everything the agent emits. Network calls, commits, comments, file writes. If the agent tries to exfiltrate, you want it in an audit trail.
• Run adversarial evals before shipping. The category default right now is “no one tests the CI agent against prompt injection before wiring it to secrets.” That is how three vendors shipped the same bug.

The layer this doesn’t cover

This is an agent-layer attack. Red-teaming the foundation model won’t find it. Scanning the deployed app won’t find it. The attacks that keep landing on vibe-coded products — missing RLS, hardcoded keys, BOLA, open buckets — are a different class of problem at a different layer. Both are real. Both are underdefended.

Bottom line

If your CI runs an AI agent and you have not done an adversarial eval against prompt injection, your pipeline is the attack surface. The vendors patched. They did not tell you. Act accordingly.

Source: aiflow.news — AI News, April 15, 2026