GitHub MCP token scope: what changes for private repo exposure?

TL;DR: A public GitHub issue can steer an MCP-connected coding agent into reading private repositories and publishing the contents back out, according to Repello AI's analysis of Invariant Labs research. The core failure is a token that spans trust levels, not a code defect, so the control is per-session repository scoping rather than a version bump.

Editorial analysis by NHI Mgmt Group, based on content published by Repello AI: “GitHub MCP Server Security: The Private Repo Exfiltration Problem”.

Key questions

Q: What breaks when an MCP agent can read public issues and private code in the same session?

A: The trust boundary collapses.

Q: Why do overbroad repository tokens increase the risk of prompt injection?

A: Because prompt injection becomes meaningful only when the agent can use the injected instruction against data it should not reach.

Q: What do security teams get wrong about read-only GitHub tokens?

A: They assume blocking writes closes the problem.

Practitioner guidance

• Scope each session to one repository Issue a token that can only reach the repository being worked on, so a public triage session cannot touch private code.
• Separate public and private agent sessions Do not reuse a session that has read attacker-controlled public content for later work in a private repository.
• Gate write operations explicitly Require confirmation before creating pull requests or issue comments, because those are the channels that can publish sensitive context outward.

Bottom line: The main risk is not a code vulnerability in GitHub's MCP server but a trust-boundary failure caused by one token spanning public and private repositories.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →