The “S” in MCP Stands for Security

Original Article ↗ Hacker News Discussion ↗

IoT Parallels & Principle of Least Privilege

  • Several comments compare MCP’s situation to insecure IoT: too much default trust, weak segmentation, and “missing S” for security.
  • Strong push that tools/agents should operate with least privilege; a code assistant shouldn’t effectively get full control of the machine by default.

“Nothing New” vs “This Is Different”

  • One camp sees MCP risks as similar to any plugin ecosystem (npm, VS Code extensions, browser add‑ons): if you run third‑party code, it can pwn you.
  • Others argue MCP is worse because it mixes trusted and untrusted tools through an LLM, without the isolation/sandboxing browsers and OSes enforce.

Tool Poisoning, Confused Deputy & Agent Attacks

  • Key concern: tool poisoning and “tool shadowing,” where a malicious MCP tool can steer the LLM into using other, more privileged tools (confused deputy).
  • Because all tool specs/instructions sit in the same context, an untrusted tool can indirectly cause leakage of secrets from a trusted tool.
  • MCP servers can change behavior over time (“rug pull”), so a previously benign tool can become malicious without the client noticing.

Local vs Hosted MCP & Sandboxing

  • Distinction between local MCP servers (implicitly trusted, but still dangerous) and remote/hosted MCP services (harder to verify, higher risk).
  • Suggested mitigations: run MCP servers in isolated VMs/containers, use WASM sandboxes, OCI‑style signing/verification, strong firewalling and zero‑trust assumptions.
  • However, commenters note sandboxing only addresses implementation bugs (e.g., unsafe shell calls), not instruction‑level/prompt‑injection attacks.

LLM Limits & Inherent Insecurity

  • Long sub‑thread: LLMs fundamentally can’t reliably distinguish “instructions to follow” from “data to analyze,” making prompt injection and confused‑deputy attacks intrinsic.
  • Some argue secure agentic systems may be impossible beyond narrow, tightly constrained domains; others look to future guardrails, privilege levels, and “instruction namespacing.”

MCP Design, Scope & Observability

  • Confusion about what MCP actually is: roughly a “tool use” / JSON‑RPC‑style protocol, intended primarily for local tools, not necessarily for SaaS backends.
  • Critiques of MCP spec and ecosystem: immature security model, no integrity guarantees for tool specs, weak or missing logging/auditing and metrics.
  • Several see today as “OWASP 2003 for AI”: experimentation dominates, security is an afterthought, and best practices (zero trust, version pinning, tainting flows) are still emerging.

Hype, Documentation & Ecosystem Concerns

  • Some view MCP enthusiasm as hype plus love of architecture; others note it is genuinely useful and “consumer‑grade” easy, which accelerates risky adoption.
  • Non‑experts are rapidly using MCP servers and Docker images they don’t understand, often “vibe‑coding” and running unvetted blobs, echoing past waves of insecure web and plugin tooling.