Running the GitHub MCP Server in Read-Only Mode for AI Agents

What read-only mode does and does not do

An MCP server advertises tools that a client can discover and call. GitHub MCP tools map to discrete operations, such as listing repositories or getting branches. Write-capable tools sit alongside them: creating or updating files, opening issues, commenting on or merging pull requests. For an AI agent or coding assistant, the practical question is which of those tools exist in the session at all.

A read-only setting on the server addresses that question by keeping write-capable tools out of the offered set. It is a statement about tool exposure. It does not make the remaining read tools harmless, and it does not tell you what the agent read, when, or why.

Treat it as one layer. A sound least-privilege design for an agent connected to GitHub has three configuration layers that fail independently: the read-only setting, the selection of toolsets, and the permissions on the credential the server uses. Each should be sufficient to prevent writes on its own, so that a misconfiguration in one does not become a write capability.

Configuring the server for read-only use

The steps below apply whether the server runs locally next to the client or is reached as a hosted remote endpoint. The mechanism for applying each setting differs by deployment and server version, so record the deployment mode and the exact settings in your configuration repository rather than relying on defaults.

Start from the credential, because it is the control that still holds if everything else is misconfigured. Then narrow the server, then verify.

• Issue a dedicated credential for the agent with read-only permissions, scoped to only the repositories it must see. Prefer a narrowly scoped, short-lived token over a broad personal token tied to a developer's full access.
• Enable the server's read-only setting in the deployment configuration, not in a user-editable client setting, so the restriction is set by the team that owns the deployment.
• Select only the toolsets the agent's task requires. An agent that summarizes pull requests does not need tools for managing workflows or organization settings, even if those tools are read-only.
• Request the tool list the client receives and review every tool name and description. Confirm that no tool creates, updates, deletes, merges or comments.
• Test the negative case. Attempt a write through the agent in a non-production repository and confirm that it fails at both the tool layer and the credential layer.
• Store the approved tool list as a baseline and compare against it whenever the server version or configuration changes.

Verifying the tool surface instead of assuming it

Verification should be based on what the client actually receives, not on what the configuration file says. A flag that is misspelled, ignored by a particular version, or overridden by another setting produces a configuration that looks restricted and is not. Enumerate the advertised tools from the client side after every deployment change and diff the result against your approved baseline.

The same discipline applies to any software that claims to enforce a read-only boundary. A published vulnerability in a different product, Claude Code, allowed shell-command parsing errors to bypass its read-only validation before version 1.0.93. It says nothing about the GitHub MCP server, but it shows that a read-only restriction is only as strong as its implementation. This is why the token layer matters: a credential without write permissions fails closed even if a tool-level restriction is bypassed.

For teams that build custom MCP components, check the SDK layer as well. The MCP TypeScript SDK before 1.24.0 did not enable DNS rebinding protection by default for HTTP-based servers, which could let a malicious website invoke tools on a user's behalf through an unauthenticated localhost server. Stdio transport servers are not affected. In the MCP Python SDK, bearer authentication could accept a valid token issued for another service when the token verifier did not independently validate the audience claim. Use fixed versions, enable authentication on HTTP servers, and validate audience.

Residual risks in read-only mode

Read-only mode removes the most direct way for an agent to change repository state. Several risks remain.

First, private content is still readable. Any repository the token can see, the agent can read and place in its context. Data an agent aggregates may carry a higher sensitivity than any single item, and it is an open question whether the user is authorized to see the aggregated result. Repository-level token scoping is the main control here.

Second, read tools carry untrusted input. Issue bodies, pull request descriptions, comments and file contents can be written by people outside your control. NIST describes modification of resources that a model ingests at runtime as the basis for indirect prompt injection. An agent that reads a malicious issue can be steered to misuse whatever other tools it has, including tools from other MCP servers in the same session.

Third, read access can become exfiltration. If the agent can also send data somewhere, such as through another tool, a web request or a generated link, content read from GitHub can leave the boundary. Read-only configuration on one server does not constrain other tools in the agent's environment.

Finally, server configuration produces no record. It cannot show which repositories were read, what was returned, or what the agent did with it.

Adding per-call enforcement and evidence in the execution path

Static configuration decides which tools exist. It does not decide whether a particular call, with particular arguments and a particular response, should proceed. That decision belongs at an enforcement point in the execution path, where each tool call and its result can be evaluated before they reach the agent or the server.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants. For MCP tool calls, policy is enforced at runtime, not reviewed after the fact. Each call can be allowed, redacted, blocked, rate limited or escalated for human approval. For example, a policy can allow reads in approved repositories, redact secrets that appear in returned file contents, block calls outside the approved scope, and route unusual requests to a person.

The same enforcement produces audit-ready evidence of what the agent was allowed to do and what it did, mapped to frameworks including NIST. This is retained as durable evidence rather than as log output to be reconstructed later. Trussed can be self-managed in the customer cloud, with configurable retention and data residency. This layer complements read-only mode and scoped tokens. It does not replace them.