What is MCP Security?
MCP security is what stops a Model Context Protocol server from becoming the easiest way into a system. The protocol standardises how agents discover and call tools; it does not decide who may call them, what they may reach, or what happens when a tool description turns hostile. Those decisions live in the server: authentication, origin and transport validation, narrowly scoped tools, rate limits and an audit trail.
Definition
MCP security is the set of controls applied to a Model Context Protocol server and its clients — authentication and authorisation, origin and transport validation, tool scoping, input and output handling, rate limiting and auditing — so that exposing capabilities to an AI agent does not expose the systems behind them.
Key takeaways
- MCP standardises the plumbing, not the trust: every server decides its own posture.
- A tool description is untrusted input to the model — it can instruct, and it can change after approval.
- Local stdio servers and remote HTTP servers have different threat models; the dangerous mistakes differ.
- Origin checks and rate limits belong in the server, because clients are not under your control.
- 'Read-only' is a property of the implementation, never of the tool's name.
Context
MCP gives an agent a uniform way to discover and invoke capabilities. That uniformity is both the value and the risk: one client can be pointed at many servers, and each server is a fresh trust decision made — in practice — by whoever pasted a URL into a config file.
Two deployment shapes dominate. A local stdio server runs with the user's own privileges on their machine: there is no network boundary, so the questions are what it can read and whether it phones home. A remote HTTP server is a public endpoint: the questions become who is calling, from where, how often, and whether a browser can be tricked into calling it on a user's behalf.
We operate one of each shape for this knowledge base — a public HTTP endpoint and a published stdio package — so the controls below are described as they are implemented rather than as a generic checklist.
Architecture
Decide the exposure first: public read-only capability, authenticated capability, or local-only. Everything else follows from that answer, and most incidents come from a server that never made it.
Validate the transport before doing any work. For HTTP servers, check the Origin header against an allowlist and reject browser-initiated cross-site calls before a handler runs — DNS rebinding and CSRF-style abuse both arrive that way.
Keep the server stateless wherever the protocol allows it. No session store means no session fixation, no cross-request contamination and no state to leak between callers.
Scope tools narrowly. One tool, one capability, no verbs that change with an argument — a 'query' tool that can also write is a privilege escalation waiting for the right parameter.
Rate limit per caller and answer with a real 429 and Retry-After. An agent that retries is normal traffic; an agent that retries without limits is a denial-of-service tool pointed at your own backend.
Log every call with enough shape to reconstruct abuse — tool, outcome, latency, caller identity — and nothing that turns the log itself into the breach.
Treat every tool result as untrusted content on the way back. A server that proxies external data is an indirect prompt-injection channel by construction.
Components
Benefits
- A well-scoped MCP server is a smaller attack surface than the ad-hoc integration it replaces: one protocol, one audit point, one place to revoke.
- Statelessness and narrow tools make the server cheap to reason about — the security review fits on a page.
- Standard errors and rate-limit headers make client behaviour predictable, which is itself a defensive property.
- Because everything crosses one boundary, measurement comes free: abuse and use appear in the same logs and look different.
Risks
- Tool rug pulls: a server that behaves at approval time and changes its tool descriptions later, once the client has stopped asking.
- Over-broad local servers: a stdio server holding the user's filesystem and credentials is a full agent capability with no network boundary to catch it.
- Confused deputy: the server holds credentials the caller does not, so anyone who reaches it inherits its reach.
- Silent public exposure: a remote server deployed with no auth, no origin check and no rate limit is discoverable and free to abuse.
- Injection relay: tool output taken from third-party sources and handed to the model as if it were trusted instruction.
Tools & technologies
Examples
- This knowledge base exposes a public, read-only HTTP MCP endpoint. It is stateless by design, so no session can be fixated or replayed; the tools return only published content; and every call is rate limited per hashed caller with a real 429 and Retry-After.
- Before writing an Origin rule for that endpoint we measured its own traffic first: almost every request carried no Origin header at all, none carried null, and every request that did carry one came from this site. The rule that shipped follows the measurement — reject browser-origin calls from anywhere else, allow the header-less agent traffic that is the actual audience — instead of a policy copied from a web-app default.
- The stdio package published for the same knowledge base runs locally with no credentials and no filesystem access, because all it needs is an outbound call to the public endpoint. A local server that needs nothing should be given nothing.
FAQs
- Does MCP make agents safer or less safe?
- Safer per integration, riskier in aggregate. One protocol means one place to review and revoke — but it also lowers the cost of connecting an agent to another system, and every connection is a new trust decision someone has to make.
- Do I need authentication on a read-only server?
- Not necessarily, if the data is genuinely public. You still need rate limiting and an audit trail: public does not mean free, and an unlimited public endpoint is an amplifier pointed at your own infrastructure.
- Why check the Origin header if agents do not send one?
- Precisely because they do not. The header-less traffic is the legitimate audience; a request that does carry a foreign Origin is a browser acting on someone else's behalf, which is exactly the case worth rejecting.
- What is a tool rug pull, and how do I defend against it?
- A server that presents benign tool descriptions when the user approves it and changes them afterwards. The defences are pinning the server version, re-validating descriptions when they change, and not granting a remote server capabilities you would not grant a code dependency.