Comment and Control: One Prompt Injection Hits Claude Code, Gemini CLI, and Copilot

If you have an AI coding agent reading pull requests in your repository, your CI/CD secrets are one malicious comment away from exfiltration. That is the bottom line of Comment and Control, the cross-vendor prompt injection class disclosed by security engineer Aonan Guan and Johns Hopkins researchers Zhengyu Liu and Gavin Zhong on April 15. The technique broke Anthropic's Claude Code Security Review, Google's Gemini CLI Action, and GitHub Copilot Agent — three of the most widely deployed AI coding agents in production today — using nothing more than a crafted PR title, an issue comment, or an HTML comment hidden in an issue body.

CVSS rating: 9.4 Critical. Number of CVEs assigned: zero. Number of vulnerability scanners that will alert on this in your environment: also zero. Welcome to AI agent runtime security.

What actually happened

The researchers opened a GitHub pull request and typed a malicious instruction into the PR title. Anthropic's Claude Code Security Review action picked it up as prompt context, executed the embedded command, and posted the company's ANTHROPIC_API_KEY as a comment on the same pull request. Same pattern, three agents, three exfiltration channels: PR comments for Claude, issue comments for Gemini, and a base64-encoded git commit for Copilot.

The Copilot variant is the one that should bother you most. It bypassed three runtime-level defenses GitHub had specifically added to block this exact attack class: environment filtering, secret scanning, and a network firewall. The payload was hidden inside an HTML comment that GitHub's rendered Markdown view does not display. A victim sees a benign-looking issue, assigns it to Copilot, and the agent reads the hidden instructions and creates a pull request containing a base64-encoded process environment dump that the attacker can decode at leisure.

Anthropic confirmed the finding, classified it as critical, and paid a $100 bounty. Google paid $1,337. GitHub paid $500 and called it a "known architectural limitation" — the most honest classification of the three.

Why your existing controls do not see this

Run a vulnerability scan against your repository today. Qualys, Tenable, Rapid7 — none of them have a signature for Comment and Control because there is no CVE to scan for. Vendors patched silently through GitHub Action version bumps. Your SIEM does not log it because it is a legitimate API call from a legitimate agent doing what it was designed to do: read a PR, post a comment. Your DLP does not flag it because the exfiltrated credential travels through GitHub's own API as routine workflow output.

The architectural problem is unambiguous. AI agents are granted execution tools (bash, git push, API calls) and production secrets (ANTHROPIC_API_KEY, GEMINI_API_KEY, GITHUB_TOKEN) in the same runtime that processes untrusted user input — pull request titles, issue bodies, code review comments. Every one of those fields is attacker-controlled. Every one of them is parsed as instructions by an LLM that cannot reliably distinguish data from commands.

Model-level safeguards do not stop this. Opus 4.7 will refuse to write a phishing email. It will not refuse to read $ANTHROPIC_API_KEY and post it as a PR comment, because that is a legitimate operation. Safeguards govern generation; the runtime governs operation; the gap between them is where Comment and Control lives.

The five questions every team running AI coding agents needs to answer this week

If you have Claude Code, Gemini CLI, GitHub Copilot, Cursor, or any other AI agent operating in CI/CD, run through these five questions before the next sprint planning meeting. None of them require a vendor call. All of them can be answered by your platform team or contractor in under two hours.

1. Which secrets does the agent have access to?

Every secret stored as a GitHub Actions variable is readable by every workflow step running in the same job, including AI agents. Find out exactly what your agents can read:

# From the root of your repository
grep -rh 'secrets\.' .github/workflows/ | sort -u

# Across an entire org (requires gh CLI)
for repo in $(gh repo list YOUR_ORG --limit 200 --json name -q '.[].name'); do
  echo "=== $repo ==="
  gh api "/repos/YOUR_ORG/$repo/contents/.github/workflows" \
    --jq '.[].name' 2>/dev/null | while read wf; do
    gh api "/repos/YOUR_ORG/$repo/contents/.github/workflows/$wf" \
      --jq '.content' | base64 -d | grep -oE 'secrets\.[A-Z_]+' | sort -u
  done
done

Build the list. Match each secret against the workflows that can read it. Anything that ends up in a workflow file alongside a Claude Code, Copilot, or Gemini step is a candidate for credential rotation and least-privilege scoping.

2. Are you using pull_request or pull_request_target?

This distinction is the single most important configuration choice in your AI agent setup. The pull_request trigger does not expose secrets to forked pull requests. The pull_request_target trigger does, and most AI agent integrations require it because they need write access to post comments. If you are using pull_request_target with an AI agent that processes PR titles or comments, every external contributor — including drive-by attackers who fork your repo — can inject prompts that execute with your full secret context.

Switch to pull_request wherever possible. Where you cannot, gate workflow runs behind a manual workflow_dispatch approval, an environments protection rule, or the require approval for first-time contributors setting under Actions general settings.

3. Does the agent need bash execution at all?

Stripping bash from the agent runtime would have blocked the entire Comment and Control attack chain. The agent could not have run env, ps auxeww, or cat ~/.npmrc if its tool list did not include shell execution. Most code review use cases do not need bash. Most "summarize this PR" workflows do not need bash. Audit your agent configurations and remove every tool that is not strictly required for the task. Anthropic's Claude Code, GitHub Copilot, and Gemini CLI all support tool restrictions in their action configurations.

4. Have you migrated to OIDC for cloud credentials?

Long-lived AWS_ACCESS_KEY_ID and AZURE_CREDENTIALS values stored as GitHub Actions secrets are static targets. OIDC federation issues short-lived tokens scoped to specific workflows, branches, and even individual jobs. If your AI agent compromises a workflow using OIDC, the blast radius is one job's worth of access to one cloud role for the duration of that run — typically minutes. With a static AWS_ACCESS_KEY_ID, the blast radius is whatever that key can do, until you notice and rotate.

5. What is your input sanitization strategy, and what is your defense-in-depth strategy when sanitization fails?

Static regex patterns for prompt injection do not work. The researchers demonstrated bypasses against three vendors who collectively have spent millions on injection defense. Treat input filtering as one layer in a stack, not the layer. The defense-in-depth stack that actually works:

• Input sanitization at the GitHub Action level (best-effort only).
• Strict permissions: blocks scoping GITHUB_TOKEN per workflow.
• Environment protection rules requiring human approval before secret injection.
• First-time-contributor gates under Actions settings.
• Network egress allowlists where the runner OS supports them.
• Branch protection requiring code owner review on any workflow file change.

What this means for SMBs without a platform team

The reflexive defense — switching vendors — does not work here. The attack hit Anthropic, Google, and GitHub at the same time. There is no vendor you can switch to that has solved this architecturally. OWASP's "The Attacker Moves Second" research found that under adaptive attack conditions, every published prompt injection defense was bypassed at success rates above 90 percent. This is a frontier research problem, not a configuration mistake any one vendor can fix.

For SMBs, exposure tiers break down by deployment shape. If you do not run AI coding agents yet, document a written approval process before enabling one. If a single team uses Copilot or Claude Code on internal-only repositories, exposure is bounded — run the audit and rotate the keys. If you have AI agents deployed across many repositories that accept external contributions, assume credential exposure has already happened and start the rotation conversation today.

The category problem and why it matters

Comment and Control did not get a CVE. Microsoft's Copilot Studio prompt injection (CVE-2026-21520) got one only because it had a specific code path with an identifiable patch. Comment and Control is an architectural class — there is no single fix to enumerate, no version number to track. Vendors mitigated it by adding guardrails and tightening default permissions, but the underlying capability — agents with execution tools and secrets in the same runtime as untrusted input — is unchanged.

For your supply chain risk register, that means a new category alongside the traditional ones. Call it AI agent runtime risk, track it separately from CVE-driven third-party software risk, and assign a 48-hour patch verification cadence with each AI vendor's security contact. Do not wait for the CVE because the CVE may never come. This is exactly the gap that EU AI Act high-risk obligations will start exposing in August. Your next vendor call should include one written request: "Show me your quantified injection resistance rate for my model version on my deployment platform." Document the answer. Document the refusal.

The 30-day plan

Week 1. Run the secret-exposure grep across every repo with an AI agent. List every credential the agent can see. Identify which workflows use pull_request_target. Inventory which agents have bash access.

Week 2. Rotate every secret exposed to an AI agent runtime. If your ANTHROPIC_API_KEY has been readable by a workflow processing untrusted PRs for six months, the prudent assumption is that someone could have read it. Migrate cloud credentials to OIDC and switch pull_request_target to pull_request wherever possible.

Weeks 3 and 4. Strip bash and write permissions from agents that do not need them, scope GITHUB_TOKEN per workflow, enable environment protection rules for any workflow processing untrusted input, and add "AI agent runtime" as a new category in your supply chain risk register with a 48-hour security contact cadence at each vendor.

The harder conversation

A team brings in Claude Code or Copilot because it accelerates code review and frees senior engineers. Those gains are real. So is the architectural risk. The right answer for most SMBs is not to ban AI coding agents — that ship has sailed. The right answer is to treat them like any other privileged service account: identify what they can access, scope the permissions, rotate the credentials, and audit the access pattern. The novelty is that the access pattern is driven by an LLM that processes untrusted input as instructions, which means the controls have to live one layer below where most teams currently put them.

Comment and Control is the first cross-vendor public demonstration of a class researchers have been quietly modeling for over a year. The pattern — untrusted input plus execution tools plus secrets in the same runtime — applies to Slack bots, Jira agents, email automations, and any deployment automation that calls an LLM. The question is not whether your AI agents can be tricked into leaking credentials. The question is whether you have already audited the blast radius and rotated the keys.