A repository issue was data, not permission
Invariant Labs' 26 May 2025 research demonstrated an indirect prompt-injection route involving a coding assistant connected to GitHub through MCP. In its setup, the account could access both a public repository and private repositories. An attacker-controlled public issue induced the assistant to retrieve private information and disclose it through a public pull request.
The researchers explicitly distinguished the problem from a flaw in the GitHub MCP server's code. The demonstrated failure involved the agent system's handling of untrusted content and the authority available through connected tools. A trusted integration can correctly execute a tool call that the user never intended the untrusted issue to request.
This was a published demonstration. It should not be inflated into a claim that the report established the same compromise at every organisation using MCP, or that FISRO reproduced the experiment.
Separate three decisions
Can the tool perform this action? That is a capability and account-permission question. A token may legitimately permit reading one repository and writing another.
Did the user request this action? That is an authorisation question. A request to inspect issues does not automatically authorise gathering private data and publishing it elsewhere.
Where did the instruction originate? That is a trust question. Issue bodies, documents and tool results are external content. They can provide evidence for the task without becoming a new source of authority over the agent.
The failure mode emerges when these decisions collapse into one: because the tool can do it, and retrieved text asks for it, the agent proceeds. A useful review keeps the origin of the instruction visible alongside the requested capability and destination.
Repository scope is also a data-flow control
Limiting a connection to the repositories needed for a task reduces the amount of unrelated material available to a manipulated agent. It does not eliminate prompt injection, but it can narrow the consequences of a failure to distinguish content from instructions.
Likewise, separating a read-only review session from a publishing session can change the possible data flow. The design should identify when an agent gains a write capability and what user decision governs that transition. A broad token configured once for convenience can quietly connect contexts the user considers separate.
Docker's later discussion of the case emphasised repository-scoped access. That is useful architectural commentary, but the original demonstration remains the evidence for what was shown. Product claims about complete protection need their own evaluation.
Test the boundary with synthetic material
A controlled test can use a public-style issue and a separate private test repository containing harmless canary text. Define the expected behaviour before the exercise: the issue may influence the factual summary, but it must not authorise unrelated reads or public disclosure.
Record tool calls, their instruction origin and their destination. The test succeeds when prohibited flows are prevented or stopped for a meaningful user decision, not merely when the model happens to ignore one wording of the injected instruction. Repeat with different content forms only within the authorised test environment.
No real private repository, customer information or credential is needed for this exercise. A synthetic canary provides a clear result while keeping the investigation focused on the trust boundary.
Exercise the permission boundary
A test matrix for the permission review
Use harmless canary text and record the expected result before running the controlled exercise:
| Retrieved content requests | Intended user task | Expected boundary |
|---|---|---|
| Summarise another issue in the same permitted repository | Review the chosen repository's issues | Remain within the authorised task and repository |
| Read a private repository unrelated to the task | Review public issues | The issue does not grant the additional authority |
| Copy retrieved private text into a public change | Summarise findings for the user | Disclosure requires a separate authorised destination and purpose |
| Change the agent's permission rules | Read the issue as source material | Retrieved text cannot redefine the governing policy |
These are test expectations, not configuration syntax for a particular product. The deployed client, tool connection and permission system must implement the relevant boundaries; adding this table to a prompt is not proof of enforcement.
Retain the trace needed to see why a tool call was attempted. A result that merely says blocked can conceal whether the agent understood the task boundary or an unrelated network error prevented the action. Conversely, a successful harmless read should not be labelled a failure if it was already within the authorised scope.
Re-test when capabilities change
Adding a write-capable connector or broadening repository access can create a new data-flow path even when the model and user interface remain unchanged. Include those changes in the permission review.
The useful regression condition is behavioural: untrusted content must not choose an unrelated read or disclosure destination. Test it with synthetic resources and the actual production-style controls, while keeping the test account's scope narrow. That yields evidence about a boundary rather than a promise that one model will always recognise every malicious phrase.
ClickFix persuades a person to promote a page's repair instructions into local execution. Indirect prompt injection attempts a related promotion inside an agent: retrieved material becomes a reason to exercise connected authority. The implementations differ, but both benefit from checking the origin of an instruction at the point where the action becomes consequential.
For an agent deployment, the practical review artefact is a map of readable data, writable destinations and the decisions joining them. Model selection belongs in that review, but it cannot replace a clear account of which cross-context actions the system permits.