An MCP allowlist for coding agents is the contract that decides which tools Codex, Claude Code, Copilot, and similar agents may discover, call, and repeat. The useful boundary is not the whole server. It is each tool, with scope, origin, secret handling, logging, and a blocking rule.

In 2026, MCP research analyzed 57 threats across host, client, LLM, server, external source, and authorization components (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, retrieved 2026-07-09). If an agent gets autonomous tools, tool configuration becomes part of the security pipeline.

Practical summary

  • Allow specific tools instead of whole servers for convenience.
  • Treat MCP changes as reviewable code changes.
  • Separate read, write, and execution tools with different policies.
  • Log every call so the PR carries short evidence.

Abstract diagram showing tools passing through a central control before reaching coding agents.

Why did MCP allowlists become a pipeline issue?

In 2026, the MCP study identified 57 threats and described tool poisoning as a prevalent client-side vulnerability (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, retrieved 2026-07-09). Pipelines must treat MCP as an execution surface because a bad tool can influence a patch, PR, secret, or deploy.

The common mistake is installing an MCP server because it looks useful and letting the agent decide later. That merges discovery, permission, and execution at the same point. In real software work, policy should exist before the prompt: which tools enter, in which repository, with which secret, and under which log.

This post continues the cluster on codebase RAG over MCP, Sentry MCP agentjacking, and hooks for coding agents. The difference here is tool-use governance. We are not discussing only returned data. We are discussing the gate that lets a tool exist.

In long workflows, allowlists also save context. The agent does not need to carry a whole catalog of capabilities when the harness provides only what the task allows. I use RemoteCode as context extension for Claude Code and Codex in long agentic flows when I want continuity without dumping too much history and too many tools into the main prompt; it is my own tool, so this is an editorial note.

Citable capsule: An MCP allowlist is execution control for coding agents. Because 2026 research mapped 57 threats in the MCP ecosystem (arXiv, retrieved 2026-07-09), policy should limit tools before the call.

What belongs in a private MCP registry?

In 2026, GitHub announced bring-your-own registry support with MCP allowlists in Copilot CLI, in public preview for Copilot Business and Enterprise customers (GitHub Changelog, "Copilot CLI supports custom registry based MCP allowlists", 2026, retrieved 2026-07-09). The private registry becomes the allowed source for discovery.

A private registry is not only a list of friendly names. It should store package origin, approved version, hash when useful, internal owner, exposed tools, secret scopes, permitted environment, and review contact. When an agent searches for a capability, it sees this inventory, not the whole internet.

Abstract diagram showing a central registry separating approved and blocked tools with no visible text.

GitHub launched the public MCP Registry in 2025 by noting that servers were scattered across registries, repositories, and community discussions, a situation with security risks (GitHub Changelog, "GitHub MCP Registry", 2025, retrieved 2026-07-09). In an organization, the private registry solves the same problem with one extra decision: discovery is not authorization.

Citable capsule: A private MCP registry separates discovery from permission. GitHub brought registry-based allowlists to Copilot CLI in 2026 (GitHub Changelog, retrieved 2026-07-09); teams should deny every server outside the governed source.

How do you allow tools without allowing the whole server?

In 2026, GitHub documentation for repository MCP configuration recommends specific read-only tool allowlists because Copilot cloud agent and Copilot code review can use those tools autonomously without asking for approval (GitHub Docs, "Configure MCP servers", 2026, retrieved 2026-07-09). The tool is the control unit.

Allowing * is convenient, but weak. A tool that reads an issue is not the same risk as a tool that comments on a PR. A tool that queries a log is not the same risk as one that runs a command. A good allowlist keeps the server installed, but exposes only the calls the task needs.

{
  "mcpServers": {
    "observability": {
      "type": "http",
      "url": "https://mcp.internal.example",
      "tools": ["find_alert", "read_trace"]
    }
  }
}

Use narrow names. find_alert is better than all_observability. read_trace is better than run_free_query. When a tool must write, create another path: human confirmation, separate secret, temporary branch, and PR log.

Citable capsule: The allowlist should target the call, not the server brand. GitHub Docs recommends specific read-only tools because the agent may use them without approval (GitHub Docs, retrieved 2026-07-09); * should be a reviewed exception.

How does CI block dangerous MCP changes?

In 2025, the MCP tools specification described tools as model-controlled and recommended a human in the loop to deny invocations (Model Context Protocol, "Tools", 2025-06-18, retrieved 2026-07-09). In a serious repository, that human starts at configuration review, before the agent runs.

Treat MCP files as infrastructure. Did a server, command, argument, secret, URL, tool, or wildcard change? CI should alert. If the change increases capability, require a code owner. If it adds writing, require security review. If it touches a secret, block until the environment proves the token is short-lived and scoped.

Abstract diagram showing a gate blocking risky tools before the agent with no visible text.

The same logic applies to UI configuration. GitHub Docs says repository MCP configuration is shared by Copilot cloud agent and Copilot code review (GitHub Docs, "Configure MCP servers", 2026, retrieved 2026-07-09). If two workflows use the same surface, review must account for both.

Citable capsule: MCP configuration should pass through a CI gate like IaC. The MCP specification recommends human control for model-controlled tools (Model Context Protocol, retrieved 2026-07-09); in development, that becomes reviewable diffs and code ownership.

Where do OAuth, scopes, and secrets fit?

In 2025, the latest MCP authorization specification required token audience validation and forbade accepting tokens issued for another resource (Model Context Protocol, "Authorization", 2025-11-25, retrieved 2026-07-09). Scope is not a login detail. It is an operational boundary for the agent.

Avoid permanent secrets in personal config. Prefer controlled environment variables, short-lived tokens, read-only scope by default, and step-up when an operation truly needs writing. If a tool needs files:write, it should not share a token with a read tool.

The same specification requires the access token in the Authorization header rather than the query string, and recommends retry limits when scope is insufficient (Model Context Protocol, "Authorization", 2025-11-25, retrieved 2026-07-09). For agents, a permission failure should stop or request scope, not find an alternate route.

Citable capsule: OAuth in MCP should reduce agency, not hide risk. The 2025 specification requires correct token audience, forbids query-string tokens, and recommends retry limits during step-up (Model Context Protocol, retrieved 2026-07-09).

How do you test against tool poisoning?

In 2026, MCP research evaluated seven clients against four tool-poisoning attack types and found that five did not apply static validation to tool descriptions (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, retrieved 2026-07-09). MCP tests should simulate hostile tools, not only dead servers.

Create a fake local server with suspicious descriptions, long parameters, malicious output instructions, and attempts to access data outside scope. The agent should refuse, ask for confirmation, or be constrained by the harness. If it executes without friction, the allowlist exists only as documentation.

OWASP lists prompt injection, insecure plugin design, and excessive agency among LLM application risks (OWASP, "Top 10 for Large Language Model Applications", 2025, retrieved 2026-07-09). MCP crosses those risks because the tool becomes a bridge between text, external systems, and action.

Citable capsule: Tool-poisoning tests validate the agent boundary. The 2026 study showed five of seven clients without static validation (arXiv, retrieved 2026-07-09); teams should test descriptions, parameters, outputs, and out-of-scope calls.

What should you implement this week?

In 2026, GitHub launched Agent Finder with discovery from a chosen registry and managed settings that limit which resources agents may discover and use (GitHub Changelog, "Agent finder for GitHub Copilot now available", 2026, retrieved 2026-07-09). The practical path is layered control over discovery, permission, and execution.

Start with inventory. List the MCP servers used by Codex, Claude Code, Copilot, IDEs, and CI automation. Then mark read, write, and execution tools. Promote only tools with an owner, source, version, and repository-level reason into the allowlist.

Then add a gate. Any change that expands tools, changes a URL, changes a command, adds a sensitive variable, or allows a wildcard should fail until review. In the PR, ask the agent to record which tools it called, with summarized arguments and verifiable results. Without that trail, the reviewer cannot tell whether the patch came from trustworthy context.

Finally, connect this to your PR evals for coding agents and the self-correcting CI loop. MCP should not be an exception to the harness. It is an operational input to the harness.

FAQ about MCP allowlists

Is a server allowlist enough?

No. In 2026, GitHub Docs recommended allowlisting specific read-only tools because Copilot can use them autonomously without approval (GitHub Docs, "Configure MCP servers", 2026, retrieved 2026-07-09). An approved server can still expose an overly broad tool.

Does a private registry replace security review?

No. In 2026, GitHub described bring-your-own registry as a way to prevent runtime use of servers outside the list (GitHub Changelog, "Copilot CLI supports custom registry based MCP allowlists", 2026, retrieved 2026-07-09). Review decides what enters the registry.

Is tool poisoning a real coding-agent risk?

Yes. In 2026, MCP research evaluated seven clients against four tool-poisoning attacks and found gaps in validation, visibility, and logging (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, retrieved 2026-07-09). Code raises impact because a tool can shape a patch.

Should every write tool be blocked?

Not always. In 2025, the MCP tools specification recommended human confirmation for sensitive operations and tool-use logging (Model Context Protocol, "Tools", 2025-06-18, retrieved 2026-07-09). Writing can exist, but it needs scope, approval, a separate token, and PR evidence.

Closing

MCP allowlists are not bureaucracy. They are how tool use becomes an engineering contract. The agent can stay fast, but only inside capabilities the team agreed to review, audit, and revoke.

Start with the smallest surface: approved read tools, blocked write tools, and no wildcard. When the team has reliable logs, add more sensitive tools with scope and code ownership. The goal is not to shrink MCP. It is to keep a useful tool from becoming invisible permission.

Sources consulted

  • arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", retrieved 2026-07-09, https://arxiv.org/html/2603.22489v1
  • GitHub Changelog, "Copilot CLI supports custom registry based MCP allowlists", retrieved 2026-07-09, https://github.blog/changelog/2026-04-16-copilot-cli-supports-custom-registry-based-mcp-allowlists/
  • GitHub Changelog, "GitHub MCP Registry: The fastest way to discover AI tools", retrieved 2026-07-09, https://github.blog/changelog/2025-09-16-github-mcp-registry-the-fastest-way-to-discover-ai-tools/
  • GitHub Changelog, "Agent finder for GitHub Copilot now available", retrieved 2026-07-09, https://github.blog/changelog/2026-06-17-agent-finder-for-github-copilot-now-available/
  • GitHub Docs, "Configure MCP servers for your repository", retrieved 2026-07-09, https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/configure-mcp-servers
  • Model Context Protocol, "Tools", retrieved 2026-07-09, https://modelcontextprotocol.io/specification/2025-06-18/server/tools
  • Model Context Protocol, "Authorization", retrieved 2026-07-09, https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
  • NSA, "Model Context Protocol: Security Design Considerations", retrieved 2026-07-09, https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF
  • OWASP, "Top 10 for Large Language Model Applications", retrieved 2026-07-09, https://owasp.org/www-project-top-10-for-large-language-model-applications/