Local vs remote MCP servers

The architectural choice underneath every product in this category. What each one actually risks, what the specification requires, and what neither of them fixes.

Last reviewed: 2026-08-19

Short answer

A local MCP server runs as a process on your own machine with your own user permissions. A remote MCP server runs on someone else's infrastructure and is reached over HTTP with OAuth.

The trade is straightforward. Local keeps data on the device and needs no third-party trust, but the server runs with everything you can reach — so a poorly written or malicious one is a serious problem, and there is no central place to revoke it. Remote gives you real identity, revocable tokens and central audit, but your data crosses a network into infrastructure you do not control. Most real setups end up with both, which is why the interesting question is not "which is safer" but "what enforces the boundary in each case".

Side by side

	Local MCP server	Remote MCP server
Where it runs	A process on your computer	A vendor's or your company's server
Transport	stdio (usually)	Streamable HTTP — the only standard HTTP binding in the 2026-07-28 revision; older servers may still use the legacy HTTP+SSE transport
Authentication	None — it inherits your user account	OAuth 2.1 where authorization is implemented; the specification makes authorization optional but says HTTP-based servers should follow its OAuth 2.1 profile
Effective permissions	Everything your user can reach	Whatever the token's scopes allow
Data location	Stays on the device	Crosses the network
Revocation	Uninstall it, or block it at a local gateway	Revoke the token centrally
Central audit	Only if something local logs it	Yes, at the gateway or server
Works offline	Yes	No
Main risk	Arbitrary code running with your rights	Third-party trust, token theft, confused deputy
Right control	A host-side permission layer or sandbox	A network gateway with IdP-backed RBAC

The specific risk of local MCP servers

This is not theoretical, and the specification itself says so. The MCP security guidance for the 2026-07-28 revision states that a client supporting one-click local server configuration must display the exact, untruncated command it is about to run, flag it as dangerous and require explicit approval — and should sandbox the server, restrict its filesystem and network access, and warn on patterns such as sudo, rm -rf or access to ~/.ssh.

The reason is simple: installing a local MCP server is installing software. It runs as you. Nothing in the protocol confines it to the folder you had in mind.

What has actually gone wrong

EscapeRoute (CVE-2025-53109 / CVE-2025-53110, July 2025) — a sandbox bypass in the official Filesystem MCP server, caused by prefix matching on paths and a fallback in path resolution.
CVE-2025-59536 (October 2025) — a code-injection flaw in Claude Code's startup trust dialog before version 1.0.111, letting project files execute code before the dialog was accepted.
CVE-2026-21852 (January 2026) — a flaw in Claude Code's project-load flow before version 2.0.65, letting a malicious repository exfiltrate data including Anthropic API keys before the user confirmed trust.
Supply chain — in September 2025 the npm package postmark-mcp was found to have been backdoored to silently blind-copy every email it sent to an attacker's address, after fifteen clean releases. Typosquatted MCP packages have followed the same pattern since.
Scanning results — security reviews of public MCP servers published through 2025 and 2026 have repeatedly reported significant proportions with serious flaws. Treat the specific percentages with care; the samples and criteria differ between studies.

Anthropic states directly that it reviews connectors against listing criteria but does not security-audit or manage MCP servers. Nobody is checking these for you.

The specific risk of remote MCP servers

Remote servers trade code-execution risk for trust and protocol risk. The specification's security document is mostly about exactly these problems:

Confused deputy — a proxy server with a static third-party client ID can be tricked into issuing credentials to an attacker. Mitigation requires per-client consent storage, exact-match redirect URI validation, and — if consent decisions are tracked in cookies rather than server-side sessions — signed __Host-prefixed cookies.
Token passthrough — the specification is explicit: an MCP server must not accept tokens that were not issued for it.
SSRF during OAuth metadata discovery — clients should enforce HTTPS and block private, loopback and link-local addresses, including the cloud metadata endpoint.
State handle hijacking — MCP is stateless with no protocol-level sessions; possession of a state handle must never be treated as authentication.
Third-party trust — your data is on their infrastructure, under their retention policy.

Neither transport protects you from prompt injection

Worth stating clearly, because it is the most misunderstood point in the category: local versus remote makes no difference to indirect prompt injection, tool poisoning, rug pulls or cross-server shadowing. Those attacks travel in content — a tool description, a document, an issue comment, an error message — and the transport is irrelevant.

What limits the damage is not the transport either. It is the blast radius: what the agent could reach if it were successfully manipulated. That is a permissions question, which is why a graded permission model is a mitigation for prompt injection even though it does nothing to detect it.

Where the standard is heading

A draft proposal, SEP-1708 "MCP Client-Brokered Filesystem Access", would move filesystem access out of a local filesystem server and into the client, with per-path user approval and revocation when the connection ends. It has been in draft since late 2025 and remains unsponsored, so treat it as direction of travel rather than something you can rely on. The direction is telling: the ecosystem agrees that the client — the thing on your machine — is the right place to make the access decision.

Practical guidance

For local servers, constrain what they can see. Either sandbox them (Docker MCP Toolkit, ToolHive) or put a permission layer in front so the server only ever receives access to folders you explicitly exposed.
For remote servers, use a gateway with real identity. Pomerium, MintMCP, TrueFoundry, Obot and the API-gateway incumbents all do this properly.
Assume every tool description is untrusted input. It reaches the model, so it is part of the prompt.
Grade permissions rather than toggling them. Read-only is not the only alternative to full access; "write only to copies" and "back up before every write" cover most real work.
Log everything locally. If you cannot answer "what did the AI touch last Tuesday", you have no incident response.

Kobel implements the first, fourth and fifth of these for Windows and Mac: a local gateway with five permission levels per resource and one timestamped activity log covering files, business apps and connected accounts — and the log is not exposed to the AI through the gateway, so a connected assistant can neither read it nor alter it.

Kobel's five permission levels

Every folder, app and account gets exactly one of these five levels. You set it by dragging a folder in and picking a colour — there is no configuration file.

GreenRead and write. The AI may open files and save changes in place.
TealWrite with automatic backup. Every change is preceded by a backup copy, so a bad edit is always reversible.
OrangeRead the original, write only to copies. The AI can work with your data but cannot alter the source file.
YellowRead only. Look, don't touch.
RedBlocked. The resource is invisible to the AI.

Keep reading

Sources

Try it on one folder

Install Kobel, drag in a single folder, set it to read-only, connect your assistant. Two minutes. Free Basis tier, no account needed.

Download Kobel See features

Kobel ships for both desktop platforms:Microsoft Store Windows 10/11 Mac App Store macOS

Frequently asked questions

What is the difference between a local and a remote MCP server?

A local MCP server runs as a process on your own machine, usually over stdio, with your own user permissions and no authentication. A remote MCP server runs on someone else's infrastructure and is reached over HTTP, normally with OAuth 2.1, so access is scoped to a token that can be revoked centrally. The specification makes authorization optional, but says HTTP-based servers should follow its OAuth 2.1 profile.

Is local MCP safer than remote MCP?

Not automatically. Local keeps data on the device and needs no third-party trust, but the server runs with everything your user account can reach and there is no central revocation. Remote gives you real identity and audit but sends your data to infrastructure you do not control. The safer setup is whichever one has an enforced boundary in front of it.

Does using a local MCP server protect me from prompt injection?

No. Prompt injection, tool poisoning and rug pulls travel in content — tool descriptions, documents, error messages — and are unaffected by transport. What limits the damage is how little the agent was allowed to reach in the first place.

Do I need OAuth for a local MCP server?

No. Local servers over stdio inherit your user account and have no authentication layer, which is precisely why the specification recommends sandboxing them and restricting their filesystem and network access.

How do I stop a local MCP server from accessing my whole home directory?

Either run it in a sandbox or container that restricts the filesystem, or put a permission layer in front of it that only exposes the folders you have added. Passing allowed directories as command-line arguments works too, but has historically been fragile — CVE-2025-53110 was exactly a bypass of that mechanism.