MCP Server Security: An Enterprise Checklist for 2026

MCP server security is the set of controls that stop an AI agent — or someone manipulating it — from doing more through a Model Context Protocol server than its user is allowed to do. An MCP server turns natural-language requests into real actions on real systems, so it needs everything an API needs (authentication, authorization, rate limits, logging) plus defences specific to AI callers: prompt injection, poisoned tool descriptions and confirmation for destructive actions. This checklist is written for CTOs, security leads and platform teams preparing an MCP server for production.

Why is MCP security different from API security?

With a normal API, a developer decides exactly which calls the code makes. With MCP, a language model decides at runtime, based on text it reads — including text from emails, tickets, web pages and documents that an attacker may control. That shifts the threat model in three ways:

• ›The caller can be manipulated. Instructions hidden in retrieved content (indirect prompt injection) can steer the model toward tools the user never asked for.
• ›Tool metadata is an attack surface. The model reads every tool's description, so a malicious or compromised server can plant instructions there.
• ›Actions chain together. A read tool that exposes data plus a send tool that reaches the outside world can combine into data exfiltration, even if each tool is harmless alone.

1. How should remote MCP servers handle authentication?

Follow the MCP authorization specification, which is based on OAuth 2.1. Your server is an OAuth resource server; your existing identity provider (Amazon Cognito, Okta, Microsoft Entra ID, Auth0) issues the tokens.

• ›Publish OAuth 2.0 Protected Resource Metadata (RFC 9728) so clients can discover your authorization server — the spec requires it for protected servers.
• ›Return 401 with a WWW-Authenticate header for missing or invalid tokens, and 403 with error="insufficient_scope" when a token lacks the scope an operation needs.
• ›Validate every token on every request, including the audience: the spec requires servers to accept only tokens issued specifically for them (RFC 8707 resource indicators).
• ›Never use token passthrough. Don't forward the client's token to downstream APIs; call them with the server's own credentials. The spec explicitly forbids accepting or passing through tokens issued for other services.
• ›Keep tokens out of URLs and logs; accept them only in the Authorization header.
• ›For local stdio servers, the spec says not to use this OAuth flow — take credentials from the environment, and keep them scoped to that one user.

2. How do you apply least privilege to tools?

Design scopes around risk, not around convenience. The MCP security guidance warns against omnibus scopes such as files:* or admin:* and recommends a minimal starting scope with step-up authorization when a privileged tool is first used.

• ›Separate read, write and administrative tools, each behind its own scope.
• ›Filter tools/list by the caller's scopes — the spec allows the tool list to vary by the authorization presented, so a read-only user should not even see refund_order.
• ›Enforce authorization inside each tool handler too; a scope in the token is not a substitute for checking that this user may touch this record.
• ›Give the server's own cloud role (for example its AWS IAM role) only the permissions its tools need, and run it in a private network when it reaches internal systems.
• ›If tools return handles for multi-step state (a cart ID, a job ID), bind them to the authenticated user and never treat possession of a handle as authorization.

3. How do you defend against prompt injection and tool poisoning?

No single control eliminates prompt injection, so layer defences and assume some injected text will reach the model.

• ›Treat everything a tool returns as untrusted data, not instructions. Return structured fields rather than large blobs of free text where you can, and label external content clearly.
• ›Limit what a successful injection can do: least-privilege scopes, no tool that can both read sensitive data and send it to arbitrary destinations, and allow-lists for outbound URLs and email domains.
• ›Review tool descriptions as code. Descriptions, names and schemas go straight into the model's context; put them through code review and alert on any change in production.
• ›Only connect servers you trust. The spec states that clients must treat tool annotations (such as readOnlyHint or destructiveHint) as untrusted unless the server is trusted — a malicious server can lie about what its tools do.
• ›Validate and sanitize tool inputs and outputs on the server — the spec lists this as a MUST, alongside access controls and rate limiting.

4. Which actions need human confirmation?

The MCP specification recommends a human in the loop who can deny tool invocations, with clear indication when tools run and confirmation prompts for sensitive operations. In practice, decide this per tool:

Clients show confirmation prompts, but don't rely on the client alone. A server can enforce its own checkpoint — for example by asking the user for input before completing a tool call, which the current protocol supports, or by returning a 'pending approval' result that only a separate approval step can release.

5. How should secrets be handled?

• ›Store downstream credentials in a secrets manager (AWS Secrets Manager, HashiCorp Vault), never in code, tool descriptions or prompts.
• ›Never return secrets, tokens or connection strings in tool results — anything returned reaches the model and may end up in a transcript.
• ›Rotate credentials and use short-lived tokens wherever the downstream system supports them.
• ›Redact personal and sensitive data at the tool boundary when the model doesn't need it (for example, mask account numbers).

6. What should you log and monitor?

• ›Every tool call: user identity, client, tool name, arguments (with sensitive fields redacted), result status, latency and a correlation ID.
• ›Every authorization event: token rejections, insufficient-scope challenges and step-up grants.
• ›Changes to the tool list and tool descriptions, so a modified description can't go unnoticed.
• ›Alerts on anomalies: a sudden burst of write calls, a user calling tools they never use, repeated failures on the same tool.
• ›Retention that matches your compliance obligations (SOC 2, HIPAA or GDPR), with logs stored outside the server's own write access.

7. How do you rate-limit an MCP server?

Agents can loop. A model that misreads an error may retry the same tool dozens of times in a minute, and an attacker with a stolen token can automate calls. Rate-limit per user, per client and per tool, with tighter limits on expensive and write tools; cap the size of results; set timeouts on downstream calls; and return clear tool errors when a limit is hit, so the model stops rather than retrying blindly.

8. How do you manage supply-chain risk from third-party MCP servers?

Open-source and vendor MCP servers save time, but they run with real credentials and can execute code on the machine that launches them. The MCP security guidance documents attacks where malicious local server configurations run arbitrary commands.

• ›Maintain an approved list of MCP servers; block unapproved ones in managed clients where possible.
• ›Review the source, pin versions and verify packages before upgrading — treat an MCP server like any other dependency with production access.
• ›Run local servers with the least privilege possible (containers or sandboxes, restricted filesystem and network access).
• ›Prefer stdio for local servers; if a local server must use HTTP, bind it to localhost and require a token. Remote HTTP servers must validate the Origin header to block DNS rebinding.
• ›Give each third-party server its own narrowly scoped credentials so a compromise is contained.

What does a production-ready MCP server look like?

• ›OAuth 2.1 with audience-validated tokens and no token passthrough
• ›Risk-based scopes, a tool list filtered per caller, and authorization checks inside handlers
• ›Layered prompt-injection defences and reviewed, monitored tool descriptions
• ›Confirmation and limits on external, destructive and financial actions
• ›Secrets in a vault, redaction at the tool boundary
• ›Complete audit logs, anomaly alerts and per-user rate limits
• ›An approved-server list and pinned, reviewed third-party dependencies

If you already have a prototype MCP server, hardening it with these controls typically takes 2–4 weeks; new production servers include them from the start. iMagic Solutions builds and hardens MCP servers for regulated teams, including HIPAA and GDPR deployments inside the client's own AWS account — if you'd like a review of an existing server, start with a free call through our MCP server development page.