Stopping Prompt Injection in GitHub Issues from Triggering MCP Write Actions

How an issue reaches a write action

Coding agents connected to GitHub through MCP read issues as part of ordinary work. The agent cannot reliably distinguish the maintainer's task from text an outsider placed in the issue body, because both arrive as tokens in the same context.

Two documented patterns show the consequence. In one GitHub MCP case, an attacker creates a malicious issue in a public repository. Prompt injection then leads the agent to fetch data from the user's private repositories and leak it into a pull request in the public repository. The AIVSS scoring document attributes this to access control gaps, specifically a failure to segregate public-facing and private data. In the second pattern, described by the OWASP Gen AI Security Project as Comment and Control, attacker-controlled GitHub text redirected three coding agents into exposing runtime secrets through comments or commits.

The chain is the same in both: untrusted text is read through a read tool, the model proposes a write-capable call, and the MCP server executes it with whatever permissions the token holds. Write channels include pull requests, comments and commits. Each step is a place to apply a control, and the later steps are the most reliable.

Why detection alone does not hold

Filtering issue text for suspicious phrases is a reasonable layer, but it cannot establish that the remaining text is safe. OWASP describes encoded and multilingual injections that evade filters. A control that depends on recognizing every malicious phrasing will eventually miss one.

Separating instruction context from tool output context is also necessary, so that issue text is never handled as instructions. It reduces exposure but does not remove it, since the model still reads the content. The durable approach is to bound the consequences: limit what the agent can do after it has ingested untrusted content, and decide on each write call whether it should proceed.

Enforcing policy on individual tool calls

Token scope sets what is possible. Runtime policy decides what is permitted for a specific call at the moment it is made. A policy point in the path between the agent and the MCP server can evaluate the tool name, the action type (read, create, update, push), the target repository and, where the enforcement point can see it, whether the session has already ingested content from an external author.

Four decisions cover most cases. Allow read calls and writes on the allowlist. Redact secret-like strings from content the agent is about to publish. Block writes that cross a boundary, such as a call that would place data from a private repository into a public one. Escalate high-impact writes, such as pushing commits or modifying repository settings, to a human approver.

Trussed enforces policy in the execution path of MCP tool calls, so these decisions are enforced at runtime, not reviewed after the fact. The scope is the individual interaction and tool call. It complements token scoping and workflow isolation and does not replace them.

Human approval and evidence

Approval works only if the approver sees what will actually happen. Show the tool, the target repository and the exact arguments, not the agent's own summary of intent, since the summary may be shaped by the injected text. Name who may approve each class of action, and keep the list of approvable actions short. If everything escalates, approvers stop reading. A narrow allowlist with a small, meaningful escalation set is the tradeoff to aim for.

Every decision should leave a structured record: tool, target, decision, the rule that applied, time, session identifier and approver where relevant. Record permitted, blocked and escalated calls alike, because blocked attempts are often the first sign of an injection. OWASP advises keeping prompt and output content in logs minimal and redacted. Record decision metadata, not full issue text. A useful review signal is an agent action that does not match the original task and follows a specific retrieval event.

Trussed produces audit-ready evidence as a product of enforcement, so the record is created by the decision itself. Deployment is self-managed in the customer cloud, with configurable retention and data residency, which matters to a regulated enterprise that must show what its agents were allowed to do and what they did.