Comment and Control: GitHub Comments That Steal CI Secrets From AI Agents
Why an AI reviewer or triage bot in your repository is a place to check, and the workflow settings that decide what a stranger's comment can reach.
Founder, Newly
Published Last updated
Comment and Control is April 2026 research showing that an AI agent running in GitHub Actions can be steered by text a stranger posts, such as an issue comment or pull request title, into revealing the keys its workflow holds. If your repository runs an AI reviewer or triage bot, check what triggers it, which secrets it can read, and what its token can write.
What is Comment and Control?
Aonan Guan published the research on April 15, 2026, with collaborators from Johns Hopkins University. It showed one idea working against three products from three vendors. The agents read text from GitHub, and that text could carry instructions the agent followed while it held credentials. The table has the facts the sources agree on. We checked each page on October 24, 2026.
| Question | What the sources say |
|---|---|
| Which agents? | Anthropic's Claude Code Security Review action, Google's Gemini CLI Action and GitHub's Copilot Agent. |
| Where did the text come from? | Pull request titles, issue comments and bodies, and hidden HTML comments inside an issue body. |
| What was exposed? | Provider API keys, the workflow's GITHUB_TOKEN, Copilot tokens and any other secret the workflow could read. |
| How did the vendors respond? | Per the researcher: Anthropic paid $100, Google paid $1,337, GitHub paid $500 and called it a known architectural limitation. The post lists no CVE for Google or GitHub. |
| Is the design change complete? | SecurityWeek reported on April 16 that the underlying issue remains: tools and secrets share a runtime with untrusted input. |
How does a comment reach your secrets?
A workflow runs when something happens in the repository, for example when someone opens an issue. If that workflow calls an AI agent, the agent reads the issue text as part of its job. A model cannot reliably tell the maintainer's instructions from instructions written inside the text it is reading. OWASP calls this prompt injection and says prevention is hard, so layered controls matter.
The risk comes from three things present at once. The agent reads text from people you do not control. It can reach secrets or run tools. And it can write somewhere a stranger can see, such as a public log or a comment. Microsoft's June 5, 2026 analysis of the Claude Code GitHub Action states the rule plainly: an AI workflow should never hold all three.
Removing any one link changes the picture. A workflow that only runs for people with write access has a smaller audience. An agent whose job holds one narrow key can reveal less. An agent that cannot post output publicly has fewer ways to hand anything over.
What has been fixed, and in which version?
Several records now exist, and they describe different flaws. The Cloud Security Alliance's August 7, 2026 note says the CVEs it lists are new and independent of the April findings. Do not read one CVE as the fix for the whole story.
| Software | Record | Fixed in | Note |
|---|---|---|---|
| Gemini CLI and run-gemini-cli | CVE-2026-12537, CVSS 10.0, April 24, 2026 | 0.39.1 / action 0.1.22 | In CI the CLI trusted the workspace folder, and a tool allowlist was ignored in one mode. |
| claude-code-action | CVE-2026-47751, moderate, May 20, 2026 | 1.0.74 | A pull request could add tool configuration the action loaded automatically. Unpinned tags received the fix on their own. |
| Claude Code (file access) | Microsoft Security, June 5, 2026 | 2.1.128 | A file-read tool could reach process environment data that holds secrets. Anthropic blocked sensitive paths. |
| Claude Code | CVE-2026-54316, per the CSA note | 2.1.163 | Listed by the CSA as an independent flaw. We did not find the vendor record, so confirm it before you rely on it. |
| A project's own workflow | GHSL-2025-093, April 3, 2026 | Fixed December 16, 2025 | An issue body was evaluated in a workflow that held an AI provider key. It shows the same mistake in an ordinary repo. |
Reading this table
A fixed version closes one flaw. It does not remove the need to limit triggers, secrets and tools. In the research, Anthropic is quoted as saying its action is not designed to be hardened against prompt injection, so the limits are yours to set.
Does this apply to an app built with AI?
Only if your code lives in a repository that runs workflows. Newly builds a real iPhone and Android app with React Native and Expo, and you can download your project code or connect your own repository. Once the code is on GitHub, the files under .github/workflows are part of your project, whoever added them.
Open that folder and look for an AI agent step. The common reasons one appears are an automatic code reviewer, an issue triage bot and a "fix this issue" agent. Then list the secrets the same job can read. In an app repository that often means an AI provider key, a backend service key and, if you added them, store or build tokens.
The same habit applies to the app itself, where anything compiled into the bundle can be read. Our guide to supply-chain attacks on AI tooling covers poisoned actions and packages, and the 15-minute app check covers keys in the bundle.
Which workflow settings should you check?
GitHub's secure use reference is the baseline. The table turns it into lines to look for in your own files, and says what each finding means.
| Look for | If you find it | Better |
|---|---|---|
issues, issue_comment or pull_request_target starting an agent | Strangers can start the agent in a public repository. Mark it detected. | Run agents only for collaborators, or add a manual approval step. GitHub warns against pull_request_target with untrusted checkouts, as the GitHub Security Lab guide explains. |
No permissions: block | The token may carry broader rights than the job needs. Unknown until you read the repository default. | Set the default to read-only for contents and raise it per job. |
secrets. used in the agent job | Untrusted text and a secret share one job. This is the pattern in the research. | Give the agent one scoped key, ideally one per workflow, and keep deploy and publishing secrets in separate jobs behind required reviewers. |
An uses: line ending in @v1 or @main | A moved tag changes what you run. You also receive fixes automatically. Both are true. | Pin a full commit SHA from the official repository and update it when advisories land. |
A github.event value inside a run: step | Title or body text reaches a shell. The project in GHSL-2025-093 had this shape. | Pass the value through an environment variable, as GitHub documents. |
| An agent allowed to run shell commands or push | A steered agent can act with those rights. | Use an allowlist of tools, and require a human to approve anything that writes. |
The CSA's May 3, 2026 note adds two points: replace long-lived keys with short-lived credentials where your cloud supports it, and treat issue bodies, comments and PR titles as untrusted input everywhere.
What if an agent already ran with your secrets?
If an agent that read public text also held a key, treat that key as exposed until you can show otherwise. The August CSA note advises treating environment variables that a CI agent can reach as effectively exposed. There is no public evidence that your repository was targeted. The point is that a run log will not always tell you.
- Turn off the trigger or the agent step first.
- Open the provider's usage page and look for requests you cannot explain.
- Create a new key, switch the workflow to it, then revoke the old one.
- Rotate any personal access token or deploy token the job could read. The per-run GITHUB_TOKEN expires on its own.
Our guide to rotating secrets after a platform breach has the order for a longer list, and the red.run.cloud rotation guide covers the website side. The security hub lists the other incident pages.
What a scan can and cannot show
Nothing outside your repository can confirm your workflow settings. Only the files, the Actions settings and the provider's usage history can, which is what the self-test below asks you to hold.
Where do you stand?
Mark each item. Everything starts as unknown, because an unchecked item is unknown. Move it to confirmed only when you hold the evidence listed under it.
Your AI agents in CI check
- Detected: You found the problem.
- Unknown: Not checked yet, or the check could not tell.
- Confirmed by owner evidence: You checked and kept the proof.
Your answers stay in this browser tab. Nothing is saved or sent.
Frequently asked questions
Does this apply if my repository is private?
It depends on who can open issues, post comments or open pull requests that start the agent. In a private repository with only trusted collaborators the reach is smaller, but GitHub's documentation notes that anyone with write access can read the repository's secrets, so the agent should still hold only the secrets it needs.
Did Anthropic, Google and GitHub fix the original findings?
According to the researcher's post, each vendor paid a bounty, and GitHub called its case a known architectural limitation. The same post and SecurityWeek's coverage describe the underlying design, an agent with tools and secrets in the same runtime as untrusted text, as unchanged. Treat the vendor fixes as narrow and keep your own limits in place.
Can a stricter system prompt stop it?
Not on its own. OWASP lists instructions in the system prompt as one control among several and says prevention is hard because of how generative models work. The dependable controls sit outside the model: what triggers the agent, which secrets it can read, what its token can write and who approves its actions.
Is pinning an action to a commit SHA enough?
No. Pinning stops a moved tag from changing what you run, and GitHub recommends it. It also means you no longer receive fixes automatically. The claude-code-action advisory notes that unpinned tags picked up the fix, so a pinned workflow has to be updated on purpose.
Will the red.run.cloud scan find this problem?
No. Both scans work from outside against a live site, and your workflow files never answer a public request. A scan can show keys shipped in your site's bundles and files like .env left reachable, which are related checks, but your .github/workflows folder needs the review on this page.
Sources
Checked on October 24, 2026. The Claude Code CVE listed by the CSA was not confirmed against a vendor record.
- Comment and Control: Prompt Injection to Credential Theft in Claude Code, Gemini CLI, and GitHub Copilot Agent, Aonan Guan, April 15, 2026
- Claude Code, Gemini CLI, GitHub Copilot Agents Vulnerable to Prompt Injection via Comments, SecurityWeek, April 16, 2026 (updated April 21)
- Comment and Control: When a GitHub Issue Steals CI Secrets, Cloud Security Alliance, August 7, 2026
- Prompt Injection in AI-Powered GitHub Actions, Cloud Security Alliance, May 3, 2026
- CVE-2026-12537: Gemini CLI workspace trust and tool allowlist bypasses, GitHub Advisory Database (GHSA-wpqr-6v78-jr5g)
- CVE-2026-47751: claude-code-action project MCP configuration in pull requests, GitHub Advisory Database (GHSA-8q5r-mmjf-575q)
- Securing CI/CD in an Agentic World: Claude Code GitHub Action case, Microsoft Security, June 5, 2026
- GHSL-2025-093: code injection in a project's claude-code-action workflow, GitHub Security Lab, April 3, 2026
- Secure use reference for GitHub Actions, GitHub Docs
- Keeping your GitHub Actions and workflows secure: preventing pwn requests, GitHub Security Lab
- LLM01:2025 Prompt Injection, OWASP GenAI Security Project