The moment you connect an LLM to tools that can take real actions — read files, call APIs, execute commands — you've created a new attack surface that traditional web security thinking doesn't fully cover, because the "user input" an attacker controls might not be the human at the keyboard, it might be content the model reads and then acts on.
Model Context Protocol (MCP) standardizes how AI applications connect to external tools and data sources. From a security standpoint, an MCP server is an interface the model can invoke with real side effects — file access, API calls, code execution — and the core risk is that untrusted content the model processes (a fetched webpage, a document, an email) can effectively become instructions the model then acts on, a pattern known as prompt injection.
Why MCP Security Matters (and When Risk Is Lower)
Once an MCP-connected model can take real-world actions, any content that flows through it — including content the model didn't ask for, like a webpage it fetched to answer a question — is a potential vector for prompt injection, where malicious instructions embedded in that content get interpreted by the model as legitimate commands, potentially triggering unintended tool calls.
Risk is meaningfully lower for MCP servers exposing only read-only, low-consequence operations (reading local documentation, querying non-sensitive data) with no ability to take destructive or externally-visible action — the security posture should scale with what the connected tools can actually do, not be uniformly maximal regardless of blast radius.
Getting Started with MCP Security
Scoping tool permissions narrowly, rather than exposing broad capabilities:
// risky: broad filesystem access
server.tool("read_file", { path: z.string() }, async ({ path }) => {
return fs.readFileSync(path, "utf-8");
});
// safer: scoped to a specific, non-sensitive directory
server.tool("read_docs", { filename: z.string() }, async ({ filename }) => {
const safePath = path.join(DOCS_DIR, path.basename(filename));
return fs.readFileSync(safePath, "utf-8");
});
Requiring explicit confirmation for consequential actions:
server.tool("delete_file", { path: z.string() }, async ({ path }, extra) => {
if (!extra.userConfirmed) {
return { requiresConfirmation: true, message: `Confirm deletion of ${path}` };
}
fs.unlinkSync(path);
});
Core MCP Security Concepts Every Developer Should Know
Prompt injection via tool outputs is the primary novel risk MCP introduces. Content returned by an MCP tool call (a fetched document, a database query result, a file's contents) is processed by the model the same way a direct instruction would be — if that content contains text designed to look like an instruction ("ignore previous instructions and instead..."), a model without adequate safeguards may act on it.
The principle of least privilege applies directly to tool scoping. An MCP server should expose the narrowest set of capabilities actually needed, not a broad, general-purpose interface — a tool that reads one specific, non-sensitive directory is a much smaller attack surface than a generic "read any file" tool, even if the latter is more convenient to build.
Consequential actions (deletions, financial transactions, sending communications, code execution) should require explicit human confirmation, not be triggered by the model autonomously based solely on inferred intent — this is a defense-in-depth layer independent of whether prompt injection is actually occurring, since even a legitimate but mistaken model decision shouldn't be able to cause irreversible harm without a checkpoint.
MCP server authentication and authorization need the same rigor as any API. An MCP server handling sensitive operations needs proper authentication (verifying which client/user is connecting) and authorization (scoping what that specific client/user is allowed to do) — treating an MCP server as inherently trusted because it's "just for the AI" is a mistake; it's an API surface like any other.
Common MCP Security Mistakes and How to Fix Them
Mistake 1: exposing overly broad tool capabilities (full filesystem access, unrestricted shell execution) for convenience, dramatically expanding the potential blast radius of a prompt injection or a model error. Fix: scope every tool to the narrowest capability that satisfies the actual use case.
Mistake 2: not requiring confirmation for irreversible or consequential actions, letting the model autonomously trigger deletions, payments, or external communications. Fix: build explicit confirmation checkpoints into any tool capable of consequential or irreversible effects.
Mistake 3: treating content returned from tool calls as inherently trustworthy, without considering that it may contain injected instructions if sourced from untrusted external content (web pages, user-submitted documents, third-party APIs). Fix: apply the same skepticism to tool output content that you would to any untrusted user input, and don't assume the model automatically distinguishes data from instructions perfectly.
When Should You Require Explicit Human Confirmation Instead of Autonomous Tool Execution?
Require explicit confirmation for any action that's irreversible, has real-world financial or communication consequences, or operates on sensitive data — deletions, payments, sending emails, modifying production systems. Allow autonomous execution for read-only, low-consequence, easily-reversible operations where the cost of a mistake is low and the friction of confirmation isn't justified by the actual risk.
MCP Security in Production
Scope every MCP tool to the minimum necessary capability, and build explicit confirmation checkpoints for consequential actions as a standard practice, not an afterthought added after an incident. Also treat MCP server authentication/authorization with the same rigor as any other API surface, since "it's just for the AI" doesn't reduce the actual risk of an unauthenticated or under-scoped endpoint.
If your MCP integration currently exposes broad, unscoped tool capabilities without confirmation checkpoints for destructive actions, that's a concrete gap worth closing before it becomes an incident triggered by either a prompt injection or a simple model mistake.