MCP Server Security
Explore MCP server security challenges and best practices to protect AI agents from attacks like prompt injection and tool poisoning. Understand how to apply the principle of least privilege, OAuth authorization, input validation, and sandboxing to build secure, scalable MCP AI systems.
A development team builds a customer support agent as part of an MCP AI project. The agent has privileged read access to a production database and processes incoming support tickets automatically. The setup works well until a user submits a ticket with a hidden instruction embedded in the message body, formatted to look like a system command. The agent reads the ticket as part of its MCP workflow, interprets the embedded instruction as legitimate, and responds by exposing sensitive integration tokens through a public support thread. Three factors made this possible:
Privileged access
Untrusted input processed without sanitization
No human checkpoint before the agent acted
Each of those factors has a direct mitigation. The sections below cover the core threats and the MCP server security best practices that address them.
Why MCP expands the attack surface
A standard language model has one primary input surface: the prompt. MCP server architecture changes that fundamentally. When a model connects to tools, resources, and external services through MCP, every one of those connections becomes a potential entry point for malicious instructions.
The model trusts everything in its context window. It cannot distinguish a legitimate instruction from a malicious one embedded in a document it retrieves, a tool description it reads during discovery, or a database record it queries mid-task. This is not a flaw in any specific MCP integration. It is a structural characteristic of how LLMs process context, and it applies to every MCP deployment regardless of the MCP library or framework used to build it.
The OWASP Top 10 for LLM Applications 2025 ranks prompt injection as the number one threat to LLM-based systems. The official MCP specification responds to this directly, stating that there SHOULD always be a human in the loop with the ability to deny tool invocations. Building with MCP means treating this as a design requirement, not an afterthought. ...