▸ SECURE CONNECTION ▸ LATENCY: 4.2ms ▸ AGENTS: 17,432 ▸ THREAT LEVEL: NOMINAL
ROGUE TERMINAL v1.0 ESC to close
← Back to blog
April 27, 2026 by Rogue Security Research
prompt-injectionCI/CDcoding-agentssupply-chainOWASPASI01ASI03ASI04

Comment and Control: When GitHub Comments Own Your Coding Agent

If your coding agent can read GitHub issues and pull requests, your repo metadata is now an execution surface. A new cross-vendor prompt injection method, nicknamed Comment and Control, showed the same pattern working across multiple AI coding agents by abusing PR titles, issue bodies, and even hidden HTML comments.

untrusted textsecrets in runtimetool executionarchitecture fix

The real takeaway

This story is being told as a prompt injection story.

It is not.

It is an isolation story:

  • untrusted content flows into the agent
  • the agent can run tools
  • the same runtime contains production secrets

That combination turns GitHub into an attacker-controlled control plane.

Comment and Control: the minimal chain that keeps repeating
[IN]
Untrusted repo text
PR title, issue body, comment, template
->
[AGT]
Agent ingests it
It is designed to read and obey
->
[TOOL]
Tools run
Shell, git push, API calls
->
[KEY]
Secrets exposed
Tokens in env and config
->
[EG]
Exfil via GitHub
Logs, comments, findings, artifacts
Why this keeps working

Prompt injection is not a bug in a model. It is a property of a system that treats natural language as both data and instruction. If you do not separate those two roles at the boundary, you will keep rediscovering the same incident in different clothes.

What changed this week

Security researchers demonstrated a single technique that could be adapted across multiple coding agents. The details differ, but the structure stays the same:

  • payload delivery through repo metadata (issues, PRs, comments)
  • instruction hiding (for example in HTML comments)
  • agent execution in a privileged runtime
  • credential theft and exfiltration through first-party surfaces

This is not limited to GitHub. GitHub is just the cleanest reproduction environment because the data plane (repo text) and the control plane (automation) are already connected.

Treat repo metadata as a supply chain

When teams say “we do not run untrusted code”, they usually mean “we do not run untrusted binaries”.

Agentic systems force a harder statement:

  • you are also running untrusted text
  • and you are running it inside a privileged interpreter

The interpreter is the agent.

SurfaceWhy security teams underestimate itAgent realityFailure mode
PR titleLooks like metadataOften gets injected into the agent context verbatiminstruction smuggling
Issue body”Just a ticket”Becomes a task spec the agent tries to satisfygoal hijack
HTML commentInvisible to humansStill parsed and processed by the modelstealth payload
CI logs”Internal”Common exfil path that looks like normal outputfirst-party exfiltration

Mapping to OWASP Agentic Top 10 (2026)

This incident chain spans multiple categories at once:

  • ASI01 - untrusted text shifts the agent goal from “review” to “extract”
  • ASI03 - the agent has identity and privilege through CI tokens and repo permissions
  • ASI04 - repo metadata is an upstream supply chain input

The most common mistake is treating this as “a prompt injection issue” and responding with more prompt filtering.

Prompt filtering helps. It does not fix the architecture.

The three-boundary architecture that actually holds

If you want a practical mental model, use three boundaries. Each boundary is a place where you can make the system deterministic.

Three boundaries for coding agents

[B1] Input boundary
Label untrusted text as data, not instruction. Strip hidden tokens and normalize markup. Never treat repo text as authoritative policy.
[B2] Capability boundary
Run the agent in a runtime that has only the tools required for the task. Security review agents do not need broad process inspection or arbitrary shell commands.
[B3] Egress boundary
Assume GitHub itself is an exfil channel. Block secrets from leaving via comments, logs, artifacts, and “security findings” outputs.
[JIT] Just-in-time secrets
Do not inject tokens into the same environment where untrusted text is parsed. Fetch secrets only for the moment they are required and scope them to a single action.
[TRC] Trace every tool call
If you cannot answer “what did the agent do” from logs, you will not be able to prove impact. Record tool calls, parameters, and destinations.
[KILL] Kill switch per run
Support immediate termination of a single run and revocation of its credentials. “Stop everything” is not an incident response plan.

Bottom line

If your agent can read it, an attacker can write it.

Repo metadata is not harmless when an agent treats it as instruction. The fix is not better wording. The fix is isolating untrusted text from secrets and from tools.