MCP has fundamental security and UX problems — protocol security, tool risk levels, and prompt injection¶
Insight: MCP's rapid adoption has outpaced its security model. Three categories of problems exist: (1) Protocol security — auth was initially absent, local stdio servers create a low-friction path for running malicious code, and server implementations commonly trust/exec their inputs. (2) UX limitations — no concept of tool-risk levels (read_journal vs. delete_files are treated equally), no way for users to set boundaries on agent autonomy. (3) Prompt injection — the LLM "intention-translator" between user and tools creates a new attack surface where malicious tool descriptions or responses can redirect agent behavior.
Detail: Written by an MCP fan and power user (Shrivu uses MCP daily in Cursor for debugging autonomy — screenshot_url, get_browser_logs, get_job_logs). Key technical issues: (a) Auth spec was added late and is still contested via ongoing RFC, (b) stdio-based servers instruct non-technical users to download and run arbitrary code, (c) MCP has no equivalent of Android's permission model — no way to mark tools as "harmless," "costly," or "irreversible," (d) Tool descriptions are part of the prompt, meaning a malicious MCP server could inject instructions that redirect the agent. This article complements Simon Willison's "Lethal Trifecta" analysis by providing a more systematic taxonomy of MCP vulnerabilities.
Sources
- Shrivu Shankar — "Everything Wrong with MCP" (2025-04-13)