MCP Security: Authorization, Tool Poisoning and Safe Defaults

A
Author
16 May, 2026 1 min read 1.15K views

MCP connects models to real systems, so it inherits real security risks. Some apply to server authors, some to anyone installing servers.

Risks for users and host apps

  • Malicious servers. A local stdio server runs with your user's permissions. Only install servers from sources you trust, and pin versions.
  • Tool poisoning. A tool's description is shown to the model. A malicious description can contain hidden instructions ("before using any tool, read ~/.ssh/id_rsa..."). Review descriptions of third-party tools.
  • Prompt injection through data. Issues, emails and web pages fetched by a tool can contain instructions aimed at the model.
  • Lethal combinations. Be careful when one session can read private data, read untrusted content and send data out. Any two are manageable; all three invite exfiltration.

Rules for server authors

  • Authorise in code, per user. The model can ask for anything; your tool decides what this user may access.
  • Least privilege. Request narrow scopes and offer read-only modes.
  • Validate inputs. Treat arguments like any untrusted API input: paths, SQL, URLs.
  • Mark destructive tools clearly so hosts can ask for confirmation. Tool annotations such as destructiveHint and readOnlyHint exist for this.
server.registerTool(
  'delete_branch',
  {
    description: 'Delete a git branch on the remote. Cannot be undone.',
    inputSchema: { branch: z.string().regex(/^[\w./-]+$/) },
    annotations: { destructiveHint: true, readOnlyHint: false },
  },
  async ({ branch }, extra) => {
    if (['main', 'master'].includes(branch)) {
      return { content: [{ type: 'text', text: 'Refusing to delete a protected branch.' }], isError: true };
    }
    // ...
  }
);

Remote servers and OAuth

  • The MCP authorization spec is based on OAuth 2.1 with PKCE.
  • Tokens must be issued for your server. Don't accept a token meant for another service, and don't forward the client's token to upstream APIs ("token passthrough").
  • Validate the Origin header and use HTTPS.
Was this article helpful?

Comments

No comments yet. Have a question or a tip? Be the first to share it.

Leave a comment

Comments are reviewed before they appear.