PathweysAI Engineer Track · Mcp
MCP Security Model
MCP Security Model
MCP security is the discipline of safely running servers you do not fully control, that expose tools capable of acting on your behalf. The core concerns: deciding whether to trust a given server before connecting to it, scoping exactly what it is authorized to do, treating content it returns as potentially hostile, protecting credentials from exposure, and accepting that a compromised or simply malicious server can exfiltrate data or take unwanted actions.
Why this matters
An MCP server is effectively arbitrary code with tool access, connecting to one you have not vetted is comparable to installing an unknown package with network and file permissions. As adoption of the protocol grows, server security becomes a real and growing attack surface, and assuming a server is safe just because it follows a standard protocol is a genuinely dangerous mistake.
MCP security model
MCP servers can execute code and touch real data, so their security model deserves genuine attention rather than being taken for granted. The core principle is that the server is itself a trust boundary: the model and any content that passes through it must be treated as untrusted input by default. Three specific threats make up the real threat model. Tool poisoning happens when a malicious or compromised server returns a tool result that contains a prompt-injection payload designed to hijack the model reading it. Over-privilege happens when a server is exposed with more access, write permissions, secrets, network reach, than the actual task genuinely needs. And untrusted remote servers simply means that connecting to any third-party MCP server grants it whatever its tools are actually capable of doing, no more and no less. The mitigations that matter are least privilege, exposing only the tools genuinely needed, input and output validation, and connecting only to servers that have actually been vetted, especially remote ones.
Treat every MCP server as a trust boundary and every one of its tool outputs as untrusted input. Least privilege and output validation are non-negotiable, not optional hardening.
Hardening an MCP deployment
Hardening an MCP deployment for production rests on a few concrete steps. Least-privilege tools means exposing read-only capabilities wherever possible and gating any write action behind explicit, deliberate approval rather than allowing it by default. Validating inputs and outputs means never passing a tool's arguments straight into SQL or a shell command; the model's arguments need exactly the same validation any other untrusted user input would receive. Authenticating remote servers means any streamable-HTTP server genuinely needs TLS and real authentication, bearer tokens or OAuth, and should never be exposed without them. And pinning and auditing means version-pinning every server actually run in production and reviewing precisely what tools a remote server exposes before ever connecting to it for the first time. The failure to avoid above all others is connecting to an unknown remote MCP server purely out of convenience and handing it a database tool, which is arbitrary code execution with a few extra, reassuring-looking steps in between.
Least privilege, input and output validation, authenticated remote connections, and version pinning together are what make an MCP deployment safe. MCP's power is precisely why it has to be gated this carefully.
Worked example
A team that connects to a convenient-looking community MCP server offering a 'full database access' tool, without first checking what that tool's description or schema actually allows, effectively hands that server's author the same level of access to their database that any member of their own engineering team has, a risk that a quick audit of the tool's actual scope before connecting would have surfaced immediately.
Practice
Adopt a third-party MCP server with a genuinely dangerous tool, such as file write or send message. Write a threat model and apply concrete mitigations, scoping, a trust prompt, treating its output as untrusted, and produce a written statement of the resulting residual risk.
Interview checks
- Why does following the MCP standard itself not guarantee that a given server is safe to connect to?
- What specifically is 'tool poisoning,' and how does it differ from an ordinary prompt-injection attack?
- Why does a server's output need to be treated as untrusted even after the server itself has been vetted?
Common failure modes
- Auto-approving server connections and their tools without any explicit review step.
- Treating content returned by a server as trusted, opening the door to injection through exactly that channel.
- Giving a server credentials it does not actually need for its stated purpose.
- Assuming that because something follows the MCP standard, it is therefore inherently secure, when the standard enforces no such guarantee at all.
Resources
- MCP Specification (security & trust considerations) — The specification's own security and trust guidance; its dedicated security considerations sections are worth reading directly.
- Indirect Prompt Injection — Describes the threat model for content flowing from tools and servers into a model; MCP servers are a direct vector for exactly this attack.
Expert signals
Treating every MCP server as untrusted by default, scoping its exposed tools to the genuine minimum needed, treating anything the server returns as hostile input until proven otherwise, and being able to write a real, concrete threat model for a specific server rather than reciting general advice, while never claiming MCP is secure by design, is what separates a genuinely hardened MCP deployment from one that merely follows the standard.
Confidence
medium