How to Restrict an AI Agent to Specific Repositories in the GitHub Model Context Protocol Server

Why the credential defines repository reach

An agent connected to the GitHub MCP server acts with the permissions of the credential it is given. The server can expose a tool, but the credential decides what that tool can touch. If the credential spans many repositories or several organizations, an agent working on one task can read from or write to repositories that have nothing to do with it.

This is why credential scope is the primary control and everything else is secondary. Server settings reduce which operations the agent can invoke. They do not reduce which repositories those operations can reach if the credential is broad.

Credential reuse makes the problem worse. Agents can inherit or delegate credentials across task boundaries and to other agents, and tokens can then propagate beyond their original scope. NIST agentic-security material describes a coding assistant holding a high-privilege GitHub token that leaks into a lower-privilege orchestration agent during a task handoff. A crafted request then turns that agent into a confused deputy performing high-risk GitHub actions with the inherited token. The design lesson is to scope each token to one agent and one task, and to never pass a broad token between agents.

Configure the layers in order

Work from the credential outward. Each step assumes the one before it is in place, and each narrows a different dimension: repositories, operations, or the maximum anyone may grant.

• 1. Issue a narrow credential per agent: Use a fine-grained personal access token or a GitHub App installation token limited to the named repositories the task needs, with only the permissions that task requires. Prefer short-lived, just-in-time tokens. Give each agent its own identity and a named owner, and never share one token across agents.
• 2. Enable read-only mode where writes are not needed: Many tasks, such as code review summaries or search, need no write access. Read-only mode removes write operations from what the server exposes, which limits damage if the agent is manipulated.
• 3. Select only the toolsets and tools the task needs: Expose the minimum set of tools and avoid open-ended ones. Pay particular attention to tools that enumerate repositories, because they reveal what lies outside the intended scope.
• 4. Apply organization-level policy: Use organization controls to set the boundary for which tokens and apps may be created and what they may access, so an individual developer cannot quietly widen an agent's reach.
• 5. Record the assignment: Document each agent, its credential type, its repository list, its enabled tools and its owner. Define the response for suspected misuse, such as token revocation and access restriction.

Verify that the restriction holds

A configuration that looks restrictive is not evidence that it is. Test from the agent's side, using the same credential and server configuration the agent will use in production. Local and remote server deployments may support these options differently, so confirm each setting against the deployment you actually run.

Start with positive and negative reads. Confirm the agent can read a repository on its list, then attempt to read, search and list content in a repository that is not on the list, in the same organization and in a different one. Every out-of-scope attempt should fail. Then test enumeration: ask the agent to list repositories and confirm the result contains only the intended set.

Next, test writes. With read-only mode on, attempt to create an issue, push a change or open a pull request, and confirm each is refused. For agents that do need write access, confirm writes succeed only against in-scope repositories.

Finally, test the tool surface. List the tools the server exposes to the agent and compare them to the approved list. Repeat these checks whenever the token is rotated, the repository list changes or the server configuration is updated, because any of those can silently change reach.

What native controls cannot do

Token scoping, server configuration and organization policy are all decided before the agent runs. None of them evaluates an individual tool call at runtime. That leaves several gaps.

First, a tool that is permitted and a repository that is in scope can still be used in an unintended way. Repository content, tool metadata and messages from other agents are inputs the agent may trust without strong verification. A crafted issue or file can steer an in-scope agent toward in-scope actions that the task never intended, and nothing in the configuration will object.

Second, native settings do not make per-call decisions such as redacting sensitive content in a response, rate limiting a burst of reads, or pausing a high-risk action for a human to approve. Access is either granted or it is not.

Third, native settings do not produce durable evidence of what the agent attempted. A refused out-of-scope call may leave little trace that a security team can later present to an auditor. Without that record, you can describe what the agent was configured to do but not what it actually tried.

Fourth, scoping is only as good as its discipline. An overly broad token reused across agents defeats every other layer, which is why separate identities and owners matter.

Adding runtime policy enforcement on MCP tool calls

Policy-based access control for agents is a distinct mechanism from identity and token controls, and it complements them. Trussed enforces policy in the execution path on MCP tool calls. For each call it can allow, redact, block, rate limit or escalate for human approval, so the decision is enforced at runtime, not reviewed after the fact.

In practice this means a repository list that lives in the credential can be backed by a policy that evaluates each call against the task. A call outside the intended scope can be blocked, a response containing sensitive content can be redacted, and a high-risk write can be escalated to a person before it runs. Trussed also generates continuous audit-ready evidence from that enforcement, so attempted out-of-scope calls are recorded alongside permitted ones. For a regulated enterprise, that is the difference between describing a control and showing what the agent was allowed to do and what it did.

This layer does not replace credential scoping. A narrow credential still limits the blast radius if anything upstream fails, and runtime enforcement works best on top of a least-privilege baseline. Teams that map controls to NIST SP 800-53 access enforcement or SP 800-171 limits on system access can treat credential scope and runtime policy as complementary evidence for the same objective.