Updated 2026-10-25

Is the GitHub MCP server safe?

It is as safe as the token you give it and the repositories your agent reads. GitHub's docs recommend minimum token scopes and offer read-only and lockdown modes. Researchers showed in May 2025 that one malicious public issue can steer an agent into leaking private repository data, so limit access before you connect it.

Is the GitHub MCP server safe to use?

Yes, with limits you set yourself. It is GitHub's own open-source server, it documents how to handle tokens, and it ships read-only and lockdown modes. The main risk is not a bug in the server code. Invariant Labs, which published the best-known attack, wrote that it is "not a flaw in the GitHub MCP server code itself, but rather a fundamental architectural issue that must be addressed at the agent system level." In plain terms: any agent that reads untrusted text and holds a powerful token can be steered, so you control the damage with the token's scope and the tools you switch on.

What is the real risk with the GitHub MCP server?

Prompt injection through content the agent reads, such as a GitHub issue. In Invariant Labs' May 2025 demonstration, an attacker opened a malicious issue on a public repository. When the owner asked their agent to look at the open issues, the agent was coerced into pulling private repository data into context and publishing it in a pull request on the public repo. That write-up is from 2025, so read it as a description of the attack pattern; the controls GitHub documents now are covered below.

How does the malicious-issue attack work?

The attacker needs no access to your account. Anyone can file an issue on a public repository, and the issue text carries hidden instructions. The attack triggers when you ask your agent a harmless question that makes it read that issue. The agent then follows the planted instructions using your token, which can reach your private repositories.

Does a smarter model or tool-call confirmation fix it?

Not on its own. Invariant tested Claude 4 Opus, described as a highly aligned model, and it was still manipulated. Claude Desktop asks you to confirm each tool call by default, but Invariant notes many people switch to an "Always Allow" policy and stop watching individual actions. Keep confirmations on for write actions, and treat them as a backstop, not the defence.

What do read-only mode and lockdown mode protect against?

They cover different problems. Read-only mode disables every tool that is not read-only, even if you request it by name, and GitHub says it takes precedence over other configuration. Lockdown mode filters what the agent sees. Neither replaces a narrow token, and GitHub is explicit about lockdown's limits. Use both where they fit, then shrink the token.

What does read-only mode do?

It removes the write tools, such as creating issues. In the demonstrated attack the data left through a new pull request, so read-only mode removes that exit; that is our reading, not a GitHub claim. It does not stop an agent from reading injected text, and it does not narrow what your token can read.

What does lockdown mode do, and what does it not do?

Lockdown mode makes the server surface content in public repositories only from users with push access, so content from users without push access is left out. GitHub calls it "a best-effort content filter" for prompt-injection risk and says it is "not an authorization boundary": it does not restrict what your credential can read or write, and withheld content may still be reachable through other tools.

How do you set up the GitHub MCP server more safely?

Start from least privilege and add capability only when a task needs it. These steps use settings GitHub documents in its README and server configuration guide; the exact flag or header differs between the remote and local server, so copy it from the docs for your setup. Our DartzDabz Crew Builder template splits work into small bots, each with its own short tool list.

We may be paid by X based on how many people use our Crew Builder template.

Step by step

1. Grant only the permissions the job needs. GitHub's token guidance puts minimum scopes first: only grant the permissions that are necessary.
2. Use different tokens for different projects or environments, so one leaked or hijacked session does not reach everything.
3. If the agent only needs to look at code and issues, enable read-only mode so write tools are disabled even if someone asks for them.
4. Enable lockdown mode to filter public content from users without push access, and remember GitHub says it is a best-effort filter, not a security boundary.
5. With no configuration the server runs its default toolsets: context, issues, pull requests, repos and users. Trim that list, and keep tool-call confirmation on for write actions.
6. Keep the token in an environment variable, never commit it, and rotate it regularly, as the README advises.

What does DartzDabz say about the GitHub MCP server?

Our directory lists it as an official vendor server with an "Official · needs auth" badge. Our anonymous check cannot score servers that need sign-in or run locally, so it has no DartzDabz trust score, and a score would not replace the steps above anyway. For setup commands see our guide to the GitHub MCP server, and for the wider picture see AI agent security and prompt injection. Want new MCP servers and big trust-score changes in a free email? Use the signup box on this page.

What should you read next on DartzDabz?

• GitHub MCP Server (official) listing
• guide to the GitHub MCP server
• AI agent security and prompt injection
• best MCP servers
• what an MCP server is
• how many MCP servers is too many
• MCP server directory
• agent setups
• submit your MCP server
• free newsletter

Every number on this page is the source's own figure as of the date shown, and business results are self-reported by the operators. Links were checked on 2026-10-22.