The Comment Became the Command

The useful thing about GitHub comments is that everyone can read them. The dangerous thing about GitHub comments is that agents can read them too, and agents do not always understand the difference between "context from a stranger" and "instructions from a trusted operator."

On April 15, 2026, security researcher Aonan Guan published Comment and Control, a cross-vendor prompt injection attack against AI agents running inside GitHub workflows. The disclosure covered Anthropic Claude Code Security Review, Google Gemini CLI Action, and GitHub Copilot Agent. Each product had its own implementation details, but the common pattern was painfully simple: the agent read attacker-controlled GitHub text, folded that text into its task context, and then used privileged tools in the repository environment.

That is a bad combination. A pull request title, issue body, or hidden HTML comment is untrusted input. A GitHub Actions runner often has repository tokens, vendor API keys, and enough permission to comment, commit, or open pull requests. Glue those together with an agent that can run tools, and the line between "review this code" and "print the secrets" starts looking optional.

Three Agents, Same Shape

Guan's Claude Code finding used a malicious pull request title to steer a security review action. The agent was asked to execute commands and report the result as if it were a normal security finding. Because the action inherited environment variables from the runner, the result could include sensitive process environment data. The exfiltration channel did not need a sketchy external server. The agent could simply write the output into the workflow log or a GitHub comment.

The Gemini CLI Action variant used issue content and comments. The injected text framed itself as trusted task material and got Gemini to disclose an API key in an issue comment. The attack was not magic. It was the same old prompt injection problem, attached to a workflow where the prompt-adjacent text came from outside contributors and the runtime had secrets sitting nearby.

The Copilot Agent variant was the most theatrical because it hid the payload in an HTML comment. A human reading the rendered GitHub issue saw a harmless request. The agent, processing the underlying Markdown, saw the hidden instructions too. The reported chain bypassed several runtime defenses and pushed encoded environment data through a Git commit. Again, GitHub was not merely where the attack began. GitHub was where the stolen material came back.

The Failure Was Architectural

It is tempting to treat this as three separate bugs in three separate products. That would be tidy and reassuring, which is usually a sign to be suspicious. The deeper issue is that these systems gave agents tools and secrets inside the same environment where untrusted collaboration text became instruction material.

A normal CI job can be dangerous too, but it usually runs code paths defined by maintainers. In an agentic workflow, the task itself can be assembled from pull request titles, issue bodies, comments, and Markdown that outside contributors control. If the model treats those fields as instructions, the attacker does not need to exploit memory corruption, dependency confusion, or a vulnerable parser. The parser is the product.

The vendors did not respond identically. SecurityWeek reported coordinated disclosure, bounty outcomes, and product-specific remediation or acknowledgement. VentureBeat emphasized that at least one system card had already acknowledged that the relevant action was not hardened against prompt injection. That detail is important. This was not a mysterious black-swan condition. It was a documented class of risk that became live once the tool was wired into developer automation with credentials nearby.

Why GitHub Made It Worse

GitHub is a perfect command-and-control surface for this failure mode because it is already the place where developer automation is expected to speak. A bot comment from a code review agent looks routine. An issue comment from an AI helper looks routine. A pull request commit from an assigned agent looks routine. Security tooling that would flag a random outbound request may not object to the agent writing to the same platform it was built to use.

That makes the attack quieter. It also makes it harder to explain to teams that are used to thinking of source control as a trusted collaboration plane. The platform is trusted for identity and workflow, but the content inside it is not automatically trusted. A malicious issue is still malicious if it lives on the correct domain and uses perfect Markdown.

The Graveyard Lesson

Comment and Control belongs here because it captures the current agent security mistake in one neat loop: read untrusted text, interpret it as authority, act with privileged tools, and write the stolen result back to the collaboration platform. The agent did not need to be conscious, clever, or malicious. It only needed to be obedient in the wrong place.

The fix is not a better warning label. These tools need real privilege boundaries, strict separation between data and instructions, narrow tokens, minimized environment exposure, hardened execution sandboxes, and output channels that cannot casually carry secrets. Anything less asks a language model to distinguish hostile instructions from legitimate work while standing next to the keys.

That is not a security model. That is a very expensive comment parser with feelings.