How to make the GitHub MCP server read-only for AI agents

Read-only is a property of several layers

AI agents connected to the GitHub MCP server may be offered tools that create, modify or delete repositories, issues, pull requests and branches. Limiting an agent to read operations is a design decision, not a toggle. Controls exist at the server, at the credential and in the path between agent and server, and each one answers a different question.

The server layer determines which tools the agent can discover and invoke. The credential layer determines what GitHub will accept if a call is made anyway. A runtime policy layer determines whether a specific call, with specific arguments, is allowed in the first place. This follows a general principle in NIST guidance: access control policies should ensure data is accessed only at the required granularity and with proper credentials. Authorization is also commonly enforced per hop by checking a token's claims against the permission an endpoint requires. Treat these as independent enforcement points, so that a failure in one does not remove read-only protection entirely.

Start with the server's native controls

Begin with the server's read-only configuration, which is intended to withhold write-capable tools from the agent. Then narrow further with toolset selection, so the agent receives only the categories of functionality it needs, and with individual tool selection where you need an explicit allowlist. A tool allowlist is the stronger posture because tools added later are excluded until someone approves them. A broad toolset with a few exclusions is the weaker posture because new tools can appear by default.

Decide how you deploy the server, locally alongside the client or as a remote hosted endpoint, because that affects who controls the configuration and how it is applied. With a local process, the configuration usually sits in client-side files that users or other tooling can edit. With a hosted endpoint, confirm how the same restrictions are expressed and who can change them. Whichever you choose, record the intended configuration in version control and treat changes as reviewable.

Server configuration reduces exposure, but it is not a permission boundary. It is enforced by the software you run and configure, so a misconfigured client entry or a second server instance can bypass it.

Scope the credential to least privilege

The token is the layer GitHub itself enforces. Even if a write tool is exposed by mistake, a credential without write permission should cause the call to be rejected. Give the agent its own identity rather than a developer's personal credential, grant read-only permissions only, and limit access to the specific repositories the task needs. Prefer credential types that support narrow, repository-level permissions and expiry over broad, long-lived ones, and compare the options your organization has available against that standard.

Avoid reusing a token across agents, environments or humans. A shared credential makes it impossible to say what a given agent was permitted to do, and one over-permissioned token undermines every other control. Set a rotation schedule and a named owner.

Read-only credentials still allow the agent to read everything the token covers, including private code and issue content. If an agent reads text that contains hostile instructions, read-only access limits the damage to disclosure rather than modification, but disclosure remains a risk. Scope repositories tightly for that reason.

Where configuration stops and runtime policy begins

Server and token controls are static. They decide what is possible, but they do not evaluate an individual call. They cannot, for example, redact sensitive content from a response before it reaches the model, require a person to approve an unusual request, or treat the same tool differently for different agents and contexts. Static controls also depend on every client being configured correctly.

A runtime policy layer sits in the execution path of the tool call and decides allow, redact, block or escalate for human approval for each interaction. This reflects a general pattern in NIST API guidance, where runtime tooling applies cross-cutting policy, such as removing data for untrusted callers, instead of relying on logic built into each service. It is warranted where agents touch sensitive repositories, where several agents share infrastructure, or where you must demonstrate to an auditor what an agent was allowed to do.

Trussed enforces policy in the execution path of MCP server and tool calls, with actions that include allow, redact, block, rate limit and escalate for human approval. Enforcement is at runtime, not reviewed after the fact, and it produces audit-ready evidence of each decision. It supports a regulated enterprise that must show what its AI was permitted to do and what it did. It complements server and token configuration and does not replace them.