Comment and Control: AI Agents Leak Your Secrets Through GitHub Comments
The Setup
Here’s a fun sentence to read on a Tuesday: security researchers found that opening a pull request with the right title can trick AI coding agents into exfiltrating your API keys, tokens, and environment secrets. No social engineering required. No phishing email. Just a PR title.
The attack is called “Comment and Control,” and it works against the three biggest AI coding agents on the planet — Anthropic’s Claude Code, Google’s Gemini CLI, and GitHub Copilot Agent. All three. At the same time.
How It Works
Classic prompt injection, but with a nasty twist. Most prompt injection attacks are reactive — they sit in a document and wait for someone to ask an AI to summarize it. Comment and Control is proactive. GitHub Actions workflows auto-trigger on pull_request, issues, and issue_comment events. The AI agent fires up without any human saying “hey, look at this.”
An attacker opens a PR or files an issue with carefully crafted text in the title, body, or comments. The AI agent — running in your CI pipeline with access to your environment secrets — reads that text, interprets the injected instructions, and dutifully exfiltrates whatever it can reach. Your GITHUB_TOKEN. Your API keys. Your deployment credentials. All shipped off to an attacker-controlled endpoint because the agent couldn’t tell the difference between a task and an attack.
The Vendor Response
All three vendors acknowledged the flaw. Here’s where it gets entertaining.
Anthropic classified it as CVSS 9.4 Critical and paid out a $100 bounty. One hundred dollars. For a critical-severity vulnerability in their flagship coding agent. Google managed $1,337 (at least they have a sense of humor about it), and GitHub awarded $500 through the Copilot Bounty Program.
To their credit, patches exist. But here’s the thing — none of them issued loud public advisories. The Register had to dig it out. These companies quietly fixed the problem and moved on, which is a great strategy if you don’t want developers to know they’ve been running vulnerable agents in their CI pipelines for months.
Why This Matters
This isn’t a theoretical attack. This is “anyone with a GitHub account can try this” territory. Open-source repos accept PRs from strangers. That’s the entire point. And if your GitHub Actions workflow triggers an AI agent on incoming PRs without gating first-time contributors, you’ve built a machine that reads attacker-controlled input with access to your secrets.
The vibe coding crowd loves automation. Hook up Claude Code to do security reviews on every PR! Let Copilot Agent auto-triage issues! It sounds great in a demo. In production, you’ve given an LLM — a system that fundamentally cannot distinguish instructions from data — the keys to your infrastructure and then pointed it at untrusted input.
The Fix (That Most People Won’t Apply)
The mitigations are straightforward. Lock down your permissions key in GitHub Actions to restrict GITHUB_TOKEN scope. Use environment protection rules that require approval before secrets get injected. Gate first-time contributors so external PRs don’t auto-trigger agent workflows.
Simple, right? Now think about how many repos actually do this. Think about every “deploy your AI agent in 5 minutes” tutorial that skips the security hardening because it makes the setup look complicated. Think about every solo dev who copy-pasted a workflow YAML from a blog post and never looked at the permissions block.
The Pattern
This is the same story we keep telling, just with different actors. AI tools ship fast, security gets bolted on later, and the gap between “available” and “safe” gets filled by developers who trusted the defaults.
The AI coding agent market is in a land grab. Anthropic, Google, and Microsoft are racing to make their agents the one developers reach for. Speed wins that race. Careful security review does not. And when the inevitable vulnerability drops, the bounty is a hundred bucks and a quiet patch.
If you’re running AI agents in your CI pipeline, audit your workflow files today. Not tomorrow. Today. Because the attacker doesn’t need to be sophisticated. They just need to open a pull request.