Table of Contents
The Comment and Control attack
AI coding agents are no longer passive autocomplete tools. They read pull requests, inspect repositories, run tests, call shell commands, open tickets and sometimes post comments with credentials available to their workflow. That makes the boundary between an untrusted text field and a privileged automation runner a security boundary.
A recent disclosure by Aonan Guan, Zhengyu Liu and Gavin Zhong at Johns Hopkins University demonstrates the problem with unusual clarity. The researchers placed a malicious instruction in a GitHub pull-request title and observed an AI-powered code-review workflow disclose its own API key in a comment. The same class of prompt injection worked against Claude Code Security Review, Gemini CLI Action and GitHub Copilot Agent. The attack needed no external server and no exploit against model weights: the attacker only needed to control text that the agent would read.
The researchers called the technique “Comment and Control.” In a normal code review, a title or comment is data. To an LLM, it may also look like an instruction. If the workflow gives the model access to secrets, tools and a channel for publishing output, an attacker can turn that ambiguity into a chain of actions.
The important lesson is not that one model is uniquely unsafe. It is that the agent runtime—not the chat prompt alone—determines how much damage a successful injection can cause.
Why model safety is not enough
Prompt filtering cannot define trust
Model-level evaluations ask whether a model follows a harmful instruction, refuses a jailbreak or resists an adversarial prompt. Those tests matter, but an agent is a system composed of a model, orchestration code, tools, credentials, memory and an execution environment. A safe answer at the model boundary does not guarantee a safe action at the tool boundary.
Repository content is particularly difficult to classify. A README, issue, commit message, test fixture or pull-request title may be intentionally written by an attacker, yet the agent must still process it. Sanitizing obvious phrases can reduce noise, but it cannot turn untrusted content into trusted instructions. The correct design is to preserve provenance and constrain authority.
Fork workflows create a dangerous trade-off
GitHub Actions does not expose secrets to fork pull requests by default when a workflow uses the pull_request trigger. However, many integrations that need privileged access use pull_request_target, which executes in the context of the base repository and can expose secrets to the runner. That choice may be operationally convenient, but it expands the attack surface whenever an agent reads attacker-controlled fields.
This is a governance issue as much as a configuration issue. Teams should explicitly document which inputs are untrusted, which workflows may access them, and why a human approval gate is or is not required. “The agent only reviews code” is not a sufficient risk statement if the runner can read tokens or write to production branches.
The runtime is the blast radius
Runtime security answers questions that a model card often does not: Can the agent execute shell commands? Which files can it read? Can it reach the internet? Are secrets injected before or after untrusted content is processed? Can it publish a comment automatically? Is a write action reversible? Can an operator reconstruct every tool call after an incident?
| Layer | Typical control | Failure when used alone |
|---|---|---|
| Model | Safety training and injection evaluations | Cannot enforce permissions on tools or secrets |
| Prompt | System instructions and input filters | Untrusted text can still be interpreted as instructions |
| Runtime | Sandbox, allowlists, network and filesystem policy | Needs accurate policy and monitoring |
| Identity | Short-lived, scoped tokens | Still harmful if issued to an over-privileged agent |
| Human control | Approval for consequential actions | Can become rubber-stamping without good evidence |
Defense in depth means these layers reinforce one another. A prompt-injection-resistant model is useful, but the safest workflow assumes that an injection will eventually succeed and limits the resulting blast radius. The objective is not to promise perfect refusal. It is to make failure contained, visible and recoverable.
What system cards reveal—and omit
The VentureBeat analysis of the disclosure compared public documentation from Anthropic, OpenAI and Google. Anthropic’s Opus 4.7 system card explicitly acknowledged that Claude Code Security Review was not hardened against prompt injection, while also publishing more quantified injection-resistance information than its peers. OpenAI’s GPT-5.4 documentation described model-layer evaluations but did not publish comparable agent-runtime or tool-execution resistance rates. Google’s Gemini documentation deferred much of its methodology to earlier material and did not provide an equivalent external verification path.
These differences should not be reduced to a vendor league table. Transparency is valuable precisely because it lets a buyer identify uncertainty. A long system card can still leave deployment gaps, and a short card can conceal either weakness or simply undocumented controls. The practical question is whether a vendor can describe protections for the exact model, agent product, hosting surface, data-retention configuration and workflow trigger that a customer will use.
The disclosure also illustrates why vulnerability management for agent systems cannot depend only on CVEs. The reported issue received critical severity treatment and bounty payments, but the relevant vendors patched quietly and no corresponding NVD entry was available at the time of the report. Enterprises need a direct security contact, a patch-notification process and a way to verify runtime behavior even when a public identifier does not exist.
Seven controls for engineering teams
1. Remove secrets from routine review
Do not inject long-lived cloud keys into a code-review agent. Start with no secrets, then add the smallest credential only when a documented task requires it. Prefer read-only access and separate review from deployment.
2. Use short-lived OIDC credentials
Where CI needs cloud access, use OIDC federation and issue tokens for minutes, not static credentials for months. Bind the token to repository, branch, environment and workflow identity. Rotate any credential that may have appeared in agent output or logs.
3. Make permissions explicit
Set a restrictive permissions block for every workflow. A review agent normally needs to read source and perhaps write a proposed comment; it rarely needs unrestricted repository write access, package publishing or administrative API calls.
4. Gate consequential actions
Require a human approval before merging, changing CI configuration, opening an external issue, modifying infrastructure or sending a message outside the repository. The approval screen should show the proposed diff, tool calls and data destinations rather than a generic “approve agent” button.
5. Isolate the runner
Use a disposable sandbox with a minimal filesystem, blocked-by-default network egress and no access to production metadata services. Treat the agent action as untrusted code execution. A container is not automatically a security boundary if it shares powerful host sockets or broad credentials.
6. Log provenance and tool calls
Store the source of every instruction, the model version, retrieved documents, tool arguments, credential scope and approval decision. These records support incident response and help distinguish a model failure from an orchestration failure.
7. Test the complete workflow
Run adversarial tests against PR titles, comments, issue bodies, commit messages and generated files. Measure not only refusal rates but also secret exposure, unauthorized tool calls, network requests and persistence after a failed action. Re-test after changing the model, action version or hosting platform.
A procurement and governance checklist
Before approving an AI coding agent, ask the vendor for runtime-specific evidence. Request the scope of prompt-injection testing, the environments covered, the distinction between model-layer and tool-layer controls, and the exact default behavior for untrusted pull requests. Ask whether safeguards transfer across API, hosted, enterprise and self-hosted deployments.
| Question | Evidence to request |
|---|---|
| What happens when a PR title contains instructions? | Reproducible test results and default workflow configuration |
| Can the agent access secrets? | Secret-injection rules, redaction behavior and sample audit logs |
| Can it execute tools? | Sandbox policy, network restrictions and permission matrix |
| How are incidents disclosed? | Security contact, SLA, advisory process and patch verification method |
| What does the public evaluation measure? | Agent-runtime metrics, not only chat or model benchmarks |
Map the answers into an AI risk register. Assign an owner, a target residual risk and a review date. Security teams should not treat a vendor’s phrase such as “trusted input” as a control; they should define how trust is established, what happens when it is wrong and who carries the loss.
What this means for teams in Vietnam
Vietnamese software teams increasingly use GitHub, GitLab, cloud CI and AI assistants across small product teams. The same risk appears whether the repository is public, private or hosted by a local provider: a Vietnamese-language comment can carry an injection just as effectively as an English one, and mixed-language codebases make simple keyword filters even less reliable.
A practical starting point is a one-week inventory. List every coding agent, repository, workflow trigger, token, cloud role and external destination. Mark which agents can read private source, execute commands, create pull requests or publish comments. Then remove standing credentials from the highest-risk workflows and add approval gates to production-facing actions.
For organizations serving European customers, this work also supports broader AI governance. Article 50 of the EU AI Act applies from 2 August 2026 to several transparency situations, including direct interaction with people and certain AI-generated content. It is not a substitute for security controls, but it reinforces the need to know where AI is used, how outputs are reviewed and how responsibility is assigned.
Conclusion
Comment and Control is a useful warning because it requires no exotic exploit. It turns ordinary collaboration text into an instruction for a system that has been granted too much authority. The durable response is not to ban every AI coding assistant or to rely on a single prompt filter. It is to design the runtime as if the model may be manipulated: minimize secrets, scope identities, isolate execution, require approvals and record evidence.
Security leaders should ask one concrete question before the next deployment: “Show me the quantified injection resistance and tool-execution behavior for the exact model, agent, runner and workflow I will operate.” If a vendor cannot answer, that uncertainty belongs in the risk register—not hidden in the launch announcement.
Frequently Asked Questions
Is prompt injection the same as a traditional code vulnerability?
Not exactly. Prompt injection abuses the interpretation of untrusted content by a model, while a traditional vulnerability usually exploits a defect in deterministic code. In an agent system, however, the outcome can still include credential theft or unauthorized code execution, so it must be handled as an operational security risk.
Should organizations stop using AI coding agents?
No. They should use them in bounded workflows. Begin with read-only repositories, disposable runners, no standing secrets and human approval for writes. Expand authority only after adversarial testing demonstrates that the additional capability is justified.
What is the most important first fix?
Inventory and remove unnecessary credentials. A successful injection with no secret and no write permission has a much smaller blast radius. Then add OIDC, sandboxing, logging and approval gates in that order of practical urgency.
Where can I read the technical disclosure?
The public analysis links to the researchers’ technical disclosure and discusses the three affected agent workflows: VentureBeat’s report. Teams should validate any configuration guidance against their current vendor documentation.
Read this article in Vietnamese: Comment and Control: Vì sao AI coding agent cần bảo mật ở tầng runtime
