Remote vs Local GitHub MCP Server: Where to Enforce Policy on Agent Tool Calls

Trace one tool call, then ask who controls each hop

A Model Context Protocol (MCP) server exposes tools that an agent can call. When an agent in a coding assistant asks to list repositories, search code, or comment on a pull request, the request passes through the same four hops regardless of topology: the MCP client, the network path, the MCP server, and the GitHub API.

The useful question is not which deployment is better. It is which hops your organization operates, which of them can see the tool name and arguments in full, and which can stop a call before it executes. A remote deployment is hosted by GitHub, so the server hop is outside your administrative control. A local deployment runs where you run it, so the server hop is yours to configure, patch, monitor, and wrap.

That difference changes where enforcement can be attached and where evidence can be captured. It does not change the underlying risk: an agent can issue calls that the credential permits but the organization did not intend.

Enforcement points by topology

The table summarizes what an enterprise can generally do at each hop. It describes architectural control, not product features, and individual clients and proxies vary.

• MCP client: Remote: you control client configuration and can require approval prompts or route traffic through a proxy. Local: same, and the client often also launches the server process, which widens what must be controlled.
• Network path or proxy: Remote: a proxy you operate can sit between client and the hosted server and evaluate each request. Local: a proxy can sit between client and server, or the server can run behind your own gateway.
• MCP server: Remote: operated by GitHub, so you configure it only through the options it exposes. Local: you operate it, so you control version, configuration, process isolation, and server-side records.
• GitHub API: Both: the credential determines what executes. Scope limits apply here, but they cannot see the agent's intent or the sequence of calls.
• Evidence capture: Remote: your own record must come from the client or the path, since the server hop is not yours. Local: you can also record at the server, but an in-path decision record is still needed to show the policy outcome.

Where native controls stop

Token scopes, toolset configuration, read-only modes, and client approval prompts each reduce exposure, and each should be used. Their limit is the same: they act on capability or on a user's attention, not on the content and context of an individual call.

A scoped token decides what the credential can do. It cannot distinguish a legitimate repository read from a read triggered by instructions hidden in an issue. NIST material on agentic AI security makes a related point: legitimate tools can be used in harmful sequences that remain in policy and within the right permissions. Per-call permission checks alone may not catch that pattern, so policy should consider context and call sequence as well.

Approval prompts depend on the client behaving as expected. CVE-2025-64109 describes a case in which, after a victim clones a project and opens it with Cursor CLI, the command to run a malicious MCP server executes immediately without warning. That matters most in local topologies, where the client starts server processes.

The layer in front of the server is its own attack surface. CVE-2026-27124 describes a confused deputy flaw in FastMCP versions before 3.2.0, where the OAuthProxy used with GitHub OAuth does not properly validate user consent. It concerns FastMCP, not GitHub's own server, but it shows that any proxy brokering GitHub OAuth needs consent validation and patching.

What in-path policy adds to each tool call

NIST SP 800-207A describes proxies acting as policy enforcement points that intercept traffic in and out of applications, with authorization checked locally or against an external policy decision point. The same pattern applies to MCP tool calls: a component in the path receives the call, asks a decision point for an outcome, and only then lets the call proceed. Decisions can use run-time attributes such as identity, resource, and context, which maps well to per-call evaluation.

Five outcomes are useful to distinguish. Allow lets a call through unchanged. Redact removes sensitive content from arguments or returned data. Block stops the call. Rate limit bounds volume. Escalate holds the call for human approval.

Applied to common GitHub operations, a reasonable starting policy might allow repository reads within approved repositories and redact secrets in returned content. Code search could be rate limited to slow bulk extraction. Issue and pull request writes could be escalated for a named approver, and any read of a private repository from a session carrying untrusted input could be blocked. These are illustrative design choices, not defaults of any product.

In a remote topology, this layer attaches at the client or on the path. In a local topology it can also wrap the server process. Either way, it complements native controls rather than replacing them.

Where Trussed fits

Trussed is runtime control for AI. It enforces policy in the execution path across models, agents, tools, MCP servers, and coding assistants, at the level of individual interactions and tool calls. Outcomes include allow, redact, block, rate limit, and escalate for human approval. Enforcement is at runtime, not reviewed after the fact.

The same enforcement generates continuous audit-ready evidence, mapped to frameworks including NIST and HIPAA. Trussed can be self-managed in the customer cloud, with configurable retention and data residency, which suits regulated enterprise teams that need to keep decision records under their own control.

The topology questions above apply whichever layer you choose. Evaluate any in-path option on whether it sees tool name and arguments before execution, whether escalation records the approver, and whether the evidence record carries the fields listed in the previous section.