MCP Security: What I Learned After 95 Production Outages

I thought security was simple. Update dependencies. Use HTTPS. Do not hardcode secrets.

I was wrong.

After 95 production outages and 1,800 hours of development, I learned that Model Context Protocol (MCP) security is different. It is not like standard REST API security.

MCP creates new risks because the client is an LLM, not a human.

Here is what you must know to keep your MCP server safe.

  1. The MCP Threat Model

In REST, you know exactly who is calling your API. In MCP, the LLM acts as the middleman. This changes everything:

  • LLMs can hallucinate tool calls or parameters.
  • Users do not call tools directly. They talk to the LLM, and the LLM talks to your server.
  • Malicious clients can probe your server for hidden tools during discovery.

Your biggest threat is not just a hacker. It is a well-meaning LLM making an accidental mistake that crashes your system.

  1. Api Key Management

Many developers pass API keys in query parameters to make things easy. This is a mistake. Query parameters show up in every server log and proxy.

Follow these rules:

  • Use header authentication (Authorization: Bearer).
  • Avoid passing keys in the JSON body.
  • Issue a different API key for every client. This helps you track usage and revoke access without breaking everything.
  1. Strict Input Validation

LLMs will guess wrong. They will send the wrong types and extra parameters. You must validate every call:

  • Check if the tool name exists in your list first.
  • Reject calls with extra parameters. Do not just ignore them.
  • Match parameter types exactly. Do not coerce data types.
  • Set strict size limits on strings and arrays to prevent memory crashes.
  • Sanitize all file paths to prevent directory traversal.
  1. Layered Rate Limiting

One user prompt can trigger ten tool calls at once. This can exhaust your connection pool in seconds.

Use three layers of defense:

  • Per-API-key limits to control client usage.
  • Per-IP limits to stop brute force attacks.
  • Concurrent connection limits to keep your server alive during bursts.
  1. Prompt Injection Risks

A user can trick an LLM into calling a destructive tool. If a user tells the LLM to delete all notes, the LLM might actually do it.

Protect yourself:

  • Separate read and write operations.
  • Require manual user confirmation for any delete or update action.
  • Use the principle of least privilege for your database user.

Security is an ongoing process. Start with better key management and strict validation. These steps solve most problems.

Source: https://dev.to/kevinten10/mcp-security-what-i-learned-securing-my-mcp-server-after-95-production-outages-3hc0

Optional learning community: https://t.me/GyaanSetuAi