MCP Server Security Checklist: 15 Things to Lock Down Before You Ship

An MCP server hands an AI agent real power — the ability to read your data and act in your systems. That is exactly why it is a security target. A Model Context Protocol server that ships without scope discipline, input validation, and write-confirmation gating is one malicious prompt away from a refunded order, a deleted record, or a leaked token. This is a code-first checklist of the 15 things to lock down before you ship an MCP server in 2026, each with a TypeScript example you can copy and adapt. Since 2016, Make An App Like has shipped 500+ apps for founders in 40+ countries; these are the same controls we apply to production MCP work.

Quick Answer: Securing an MCP Server in 2026

What is the core risk? Prompt injection plus over-broad tool access — an agent tricked by malicious text into calling a destructive tool that has wide scopes and no confirmation.

What are the non-negotiables? Least-privilege scopes, input validation on every tool, explicit confirmation on destructive actions, authenticated transport, secret hygiene, rate limiting, and an audit trail of every call.

Where do most teams fail? Shipping write tools without confirmation, requesting broad scopes, logging access tokens, and skipping the audit trail — all avoidable with the controls below.

Key Takeaways

• Treat every tool argument and every tool result as untrusted input.
• Least-privilege scopes per tool shrink the blast radius of any compromise.
• Gate every destructive action behind an explicit confirmation flag — this neutralises most prompt-injection damage.
• Never build SQL or shell commands from model-supplied text; use parameterized queries and allowlists.
• A remote MCP server must be authenticated (OAuth 2.1 / bearer), HTTPS-only, with Origin checks.
• Redact secrets before logging and store them in a vault — a logged token is an incident.
• Audit every tool call so you can answer "who did what" in seconds.
• Add rate limits, timeouts, and result caps to prevent DoS and runaway cost.

Quick Facts: MCP Server Security

Why This Matters

The MCP threat model is new but the failure modes are old: injection, excessive privilege, secret leakage, and missing audit. What is new is the attacker's vector — natural-language text that the model reads and acts on. Because the agent is a confused deputy that will faithfully call whatever tool the prompt steers it toward, security has to live in the server, not the model. The controls below assume the agent will be manipulated and make sure that when it is, nothing irreversible happens without a human in the loop.

The MCP Threat Model in One Minute

Four attack surfaces matter. (1) The prompt — injected instructions in user input or in data the agent fetches. (2) The tool arguments — model-supplied values that flow into your SQL, shell, or filesystem. (3) The transport — an unauthenticated or unencrypted remote endpoint. (4) The secrets and logs — tokens that leak through responses or log lines. Every item below maps to one of these surfaces. Work the list top to bottom and sign it off before launch.

The 15-Item MCP Server Security Checklist

1. Enforce Least-Privilege Scopes Per Tool

Map each tool to the minimum scopes it needs and verify them before executing. Never request a blanket grant like write_all.

const TOOL_SCOPES: Record<string, string[]> = {
  list_orders:   ["orders:read"],
  refund_order:  ["orders:write", "payments:write"],
};

function assertScopes(tool: string, granted: string[]) {
  const required = TOOL_SCOPES[tool] ?? [];
  const missing = required.filter((s) => !granted.includes(s));
  if (missing.length) {
    throw new Error("Missing scopes for " + tool + ": " + missing.join(", "));
  }
}

2. Validate Every Tool Input

Never trust model-supplied arguments. Parse them against a strict schema and reject anything malformed before it reaches your business logic.

import { z } from "zod";

const SearchInput = z.object({
  query: z.string().min(1).max(200),
  limit: z.number().int().min(1).max(100).default(20),
});

server.setRequestHandler("tools/call", async (req) => {
  if (req.params.name === "search_customers") {
    const args = SearchInput.parse(req.params.arguments); // throws on bad input
    return runSearch(args);
  }
});

3. Gate Destructive Actions Behind Explicit Confirmation

Every irreversible tool must require a fresh confirmation flag (or a dry-run preview). This single control neutralises most prompt-injection damage.

const DESTRUCTIVE = new Set(["refund_order", "delete_product", "cancel_subscription"]);

function requireConfirmation(name: string, args: { confirm?: boolean }) {
  if (DESTRUCTIVE.has(name) && args.confirm !== true) {
    return {
      content: [{
        type: "text",
        text: "This will run " + name + ". Re-call with \"confirm\": true to proceed.",
      }],
    };
  }
  return null; // null = safe to proceed
}

4. Defend Against Prompt Injection

Assume the agent will be manipulated. Allowlist operations and parameters instead of interpolating model text into privileged commands, and clearly label tool output as untrusted data, not instructions.

const ALLOWED_TABLES = new Set(["orders", "products", "customers"]);

function readTable(table: string) {
  if (!ALLOWED_TABLES.has(table)) throw new Error("Table not allowed");
  return db.query("SELECT * FROM " + table + " LIMIT 100"); // table is allowlisted
}

// Wrap fetched content so the model treats it as data, never as commands:
function wrapUntrusted(text: string) {
  return { content: [{ type: "text",
    text: "<<UNTRUSTED_DATA>>\n" + text + "\n<<END_UNTRUSTED_DATA>>" }] };
}

5. Authenticate the Transport

A remote MCP server over Streamable HTTP must never be open. Verify a token on every request and reject anonymous callers.

export function requireAuth(req: any, res: any, next: any) {
  const auth = String(req.headers.authorization ?? "");
  const token = auth.startsWith("Bearer ") ? auth.slice(7) : null;
  if (!token || !verifyAccessToken(token)) {
    return res.status(401).json({ error: "unauthorized" });
  }
  next();
}
// app.use("/mcp", requireAuth, mcpHandler);  // OAuth 2.1 / signed bearer, HTTPS only

6. Keep Secrets Out of Logs

Store tokens in a vault and redact secret-shaped fields before anything is logged. One log line with an access token is a breach.

const SECRET_KEYS = /token|secret|authorization|api[-_]?key|password/i;

function redact(obj: Record<string, unknown>): Record<string, unknown> {
  const out: Record<string, unknown> = {};
  for (const [k, v] of Object.entries(obj)) {
    out[k] = SECRET_KEYS.test(k) ? "[REDACTED]" : v;
  }
  return out;
}

logger.info("tool_call", redact({ tool, args, authorization: token }));

7. Rate-Limit Per Caller and Per Tool

Without limits, a runaway agent loop or hostile caller exhausts your API quota and runs up cost. Add a sliding window per caller.

const WINDOW_MS = 60_000;
const MAX_CALLS = 60;
const hits = new Map<string, number[]>();

function rateLimit(callerId: string) {
  const now = Date.now();
  const recent = (hits.get(callerId) ?? []).filter((t) => now - t < WINDOW_MS);
  if (recent.length >= MAX_CALLS) throw new Error("rate_limit_exceeded");
  recent.push(now);
  hits.set(callerId, recent);
}

8. Audit Every Tool Call

Log who called what, with which arguments, and a hash of the result. When someone asks "who deleted my data," you need an answer in seconds.

import { createHash } from "crypto";

async function audit(e: {
  callerId: string; tool: string; args: unknown; ok: boolean; resultText?: string;
}) {
  await db.auditLog.create({ data: {
    callerId: e.callerId,
    tool: e.tool,
    argsJson: e.args,
    ok: e.ok,
    resultHash: e.resultText
      ? createHash("sha256").update(e.resultText).digest("hex")
      : null,
    at: new Date(),
  }});
}

9. Use Parameterized Queries

Model-supplied text must never be concatenated into SQL. Use bound parameters and a read-only role for query tools.

// NEVER — injectable:
// db.query("SELECT * FROM users WHERE email = '" + email + "'");

// DO — parameterized:
const result = await db.query(
  "SELECT id, name FROM users WHERE email = $1 LIMIT 1",
  [email]
);

10. Block Path Traversal in Filesystem Tools

Resolve every path against a fixed root and reject anything that escapes it.

import path from "path";

const ROOT = path.resolve("/srv/agent-data");

function safePath(userPath: string) {
  const resolved = path.resolve(ROOT, userPath);
  if (!resolved.startsWith(ROOT + path.sep)) {
    throw new Error("path_traversal_blocked");
  }
  return resolved;
}
// safePath("../../etc/passwd") -> throws

11. Scrub PII From Tool Responses

Strip or mask sensitive data before it flows back to the model and into transcripts and logs.

const EMAIL = /[\w.+-]+@[\w-]+\.[\w.-]+/g;
const CARD  = /\b(?:\d[ -]*?){13,16}\b/g;

function scrub(text: string) {
  return text.replace(EMAIL, "[email]").replace(CARD, "[card]");
}

return { content: [{ type: "text", text: scrub(rawResult) }] };

12. Pin Dependencies and Vet the Supply Chain

Untrusted or floating dependencies are a supply-chain risk. Pin versions, commit the lockfile, and audit in CI. Be especially careful installing third-party MCP servers you did not write.

// package.json — pin, commit package-lock.json
{
  "dependencies": {
    "@modelcontextprotocol/sdk": "1.12.0",
    "zod": "3.23.8"
  }
}
// CI:  npm ci  (not npm install)
//      npm audit --audit-level=high

13. Enforce HTTPS and Validate Origin

Serve remote MCP only over TLS, check the Origin header, and guard against DNS rebinding by binding local servers to localhost.

const ALLOWED_ORIGINS = new Set(["https://app.example.com"]);

export function checkOrigin(req: any, res: any, next: any) {
  const origin = req.headers.origin;
  if (origin && !ALLOWED_ORIGINS.has(origin)) {
    return res.status(403).json({ error: "forbidden_origin" });
  }
  next();
}
// Bind dev servers to 127.0.0.1, never 0.0.0.0

14. Set Resource Limits and Timeouts

Bound how long a tool can run and how much it can return, so one call cannot hang the server or dump a million rows.

function withTimeout<T>(p: Promise<T>, ms: number): Promise<T> {
  return Promise.race([
    p,
    new Promise<T>((_, reject) =>
      setTimeout(() => reject(new Error("tool_timeout")), ms)),
  ]);
}

const MAX_ROWS = 500;
const rows = (await withTimeout(runQuery(sql), 10_000)).slice(0, MAX_ROWS);

15. Handle Errors Without Leaking Internals

Log full detail server-side, but return a generic message to the model. Stack traces and secrets must never reach the transcript.

server.setRequestHandler("tools/call", async (req) => {
  try {
    return await dispatch(req);
  } catch (err) {
    logger.error("tool_error", { tool: req.params.name, err }); // detail stays server-side
    return {
      isError: true,
      content: [{ type: "text", text: "The tool failed. Please try again." }],
    };
  }
});

Checklist Summary

Run a Pre-Ship Security Review

Treat the 15 items as a sign-off gate, not a wish list. Before launch, walk the checklist with a second engineer, write down the scope each tool requests and why, attempt a prompt-injection on every write tool, confirm no secret appears in any log, and verify the audit trail captures a complete write. Schedule the review again whenever you add a tool, widen a scope, or move from stdio to a remote endpoint — those are the moments new risk enters. For context on where these controls fit in a full build, see our guide on the cost to build a custom MCP server and our list of the top 10 MCP servers every business should use.

Why Founders Trust Make An App Like

Founded in 2016, Make An App Like has shipped 500+ apps for founders in 40+ countries, reaches a 50,000+ founder audience through our publishing platform, and has been featured by TechCrunch as a leading partner for non-technical founders. We build and harden MCP servers for clients — this checklist is the same one our engineers run before a server goes live. If you need a partner, see our ranking of the top 10 MCP development companies in the USA.

Estimate Your Secure MCP Build

Budgeting an MCP server with security and audit built in? Get a fast, line-item estimate with our free calculator: https://makeanapplike.com/tools/app-cost-calculator

Launch Faster With a Hardened MCP Foundation

Skip months of build time with a white-label, security-reviewed MCP server or AI agent foundation: https://makeanapplike.com/buy-white-label-apps

Conclusion

MCP security is not a feature you bolt on at the end — it is the difference between an agent that helps and one that does damage. The 15 controls here cover the four surfaces that matter: the prompt, the tool arguments, the transport, and your secrets. Enforce least-privilege scopes, validate every input, gate every destructive write, authenticate the transport, keep secrets out of logs, and audit everything. Assume the agent will be manipulated, and make sure that when it is, nothing irreversible happens without a human saying yes. Ship the checklist, not just the server.

Related MCP Guides

• How Much Does It Cost to Build a Custom MCP Server? — a full cost breakdown from $8K MVP to $150K+ enterprise.
• Top 10 MCP Servers Every Business Should Use — the best ready-made MCP servers for real businesses.
• Building a Shopify MCP Server: Cost & Use Cases — what a Shopify MCP server costs to build, with architecture and code.
• Top 10 MCP Development Companies in USA (2026) — how to evaluate and hire an MCP development partner.

Frequently Asked Questions

1. What is MCP server security?

MCP server security is the set of practices that keep a Model Context Protocol server safe when AI agents call its tools — covering authentication, least-privilege scopes, input validation, prompt-injection defense, write-action gating, secret hygiene, rate limiting, audit logging, and safe error handling. The goal is to let agents act usefully without letting a malicious prompt or caller do damage.

2. What is the biggest security risk with MCP servers?

Prompt injection combined with over-broad tool access. If an agent can be tricked by malicious text into calling a destructive tool (refund, delete, send), and that tool has wide scopes and no confirmation, a single injected instruction can cause real harm. The fix is least-privilege scopes plus explicit confirmation gating on every destructive action.

3. How do you prevent prompt injection in an MCP server?

You cannot stop the model from being influenced, so you constrain what it can do. Allowlist operations and parameters instead of interpolating model text into commands, mark tool output as untrusted data rather than instructions, require explicit confirmation for destructive tools, and enforce least-privilege scopes so the blast radius of any injection is small.

4. Should MCP write tools require confirmation?

Yes — every destructive or irreversible action (refund, delete, cancel, send) should require an explicit confirmation flag or a dry-run preview before it executes, especially during rollout. This single control neutralises most prompt-injection damage, because an injected instruction alone cannot complete a write without the fresh confirmation step.

5. How do you authenticate a remote MCP server?

A remote MCP server served over Streamable HTTP should never be unauthenticated. Use OAuth 2.1 or signed bearer tokens, verify the token on every request, validate the Origin header, enforce HTTPS, and bind local development servers to 127.0.0.1 rather than 0.0.0.0. Treat the MCP endpoint like any other production API.

6. What scopes should an MCP server request?

The minimum each tool actually needs, mapped per tool rather than globally. Avoid broad grants like write_all. Define a scope list per tool, check the caller has those scopes before executing, and document why each is required. Narrow scopes shrink the blast radius of both prompt injection and credential leaks.

7. How do you secure secrets in an MCP server?

Store tokens and API keys in a secrets manager or vault, never in committed config or plain environment files in a repo. Redact secret-shaped fields before any log line is written, rotate credentials regularly, and never return tokens in tool responses. A single log line containing an access token is an incident.

8. Do I need rate limiting on an MCP server?

Yes. Without per-caller and per-tool rate limits, a runaway agent loop or a malicious caller can exhaust the wrapped API quota, run up LLM and infrastructure costs, or cause a denial of service. Add a sliding-window limit per caller and back-pressure expensive tools specifically.

9. How do you prevent SQL injection in MCP tools?

Never build SQL by interpolating model-supplied text. Use parameterized queries (bound parameters), allowlist table and column names where they must be dynamic, and prefer read-only database roles for query tools. The same rule applies to shell commands and any other interpreter the tool touches.

10. What should an MCP server security review cover before launch?

Authentication and transport, per-tool scopes, input validation on every tool, confirmation gating on destructive tools, prompt-injection handling, secret storage and log redaction, rate limits, audit logging, SQL/command/path-traversal protection, PII scrubbing, dependency pinning, timeouts and resource caps, and error handling that never leaks internals. Run it as a checklist with a sign-off before you ship.