MCP Server Security Checklist (OWASP-Mapped)

An MCP server security checklist covers seven domains: authentication and credentials, tool-level authorization, tool integrity and supply chain, inputs, outputs and context, rate limits, forensic logging, and inventory and monitoring. Each domain maps to one or more entries in the OWASP MCP Top 10, the OWASP Foundation's list of the most critical risks for systems built on the Model Context Protocol, which is a beta release at the time of writing.

Securing an MCP server means addressing authentication, tool-level authorization, rate limiting, forensic logging, and monitoring as distinct layers — not as a single configuration switch. This checklist walks through each layer in order of blast-radius risk, so you can prioritize the controls that matter most when an agent misbehaves or a connection is compromised. For the authentication layer specifically — including when to use OAuth 2.1 versus API keys — see MCP Server Authentication: OAuth 2.1 vs API Keys.

Why MCP servers need their own security posture

The Model Context Protocol is designed to give AI agents a standard, composable interface to external tools and resources. That same composability makes MCP servers a high-value target: a single server can expose database queries, file operations, API calls, and destructive actions behind one endpoint. An agent that gains broader access than it needs — or an attacker who finds an unguarded server — can reach capabilities that have nothing to do with the agent's intended task.

Traditional API security assumes a human caller who can be prompted to re-authenticate or approve sensitive actions. Agents behave differently: they call tools programmatically, often in rapid sequences, and may not surface errors to a human until after significant work is done. Controls need to be designed around this call pattern, not retrofitted from a human-facing context. The wider operating model, meaning who registers servers, who approves tools and how access is reviewed, is covered in MCP server governance; this checklist is the control layer underneath it. For a short definition of the field, see MCP security.

The checklist at a glance: seven domains mapped to the OWASP MCP Top 10

The mapping is ours, made from the entry names. The OWASP MCP Top 10 is a beta release and its entries may change, so read each entry on the OWASP project page before citing it in an assessment.

Authentication: verifying who is connecting

The first checkpoint on any MCP server is establishing that the caller is who it claims to be.

Require explicit authentication on every server. An MCP server that accepts unauthenticated connections is effectively public regardless of the network segment it sits on. Treat anonymous access as a misconfiguration, not a deployment convenience.

Choose credentials that can be rotated. Bearer tokens and API keys are the most common authentication types for MCP servers. Design your credential storage so rotation is a single operation — update the stored value and agents connecting through a managed client layer pick up the change automatically. Credentials baked into agent prompts cannot be rotated without finding and updating every instance.

Encrypt credentials at rest. Stored authentication configuration should be encrypted at rest, not held in plaintext in a database column. Envelope encryption limits the blast radius of a database-read exposure: an attacker who reads the database without the decryption key gets ciphertext, not usable credentials.

Scope the credential to the minimum surface. If your MCP server or the upstream API it wraps supports scoped tokens, use them. A token that can only read is safer than a token that can read and write, even if your current agents only read. Scope limits future misuse.

Tool-level authorization: the allow-list model

Authentication tells you who is connecting. Authorization tells you what they are allowed to do once connected.

Build an allow-list of permitted tools per agent. An agent that connects to an MCP server should only be able to invoke the tools it genuinely needs. An implicit "all tools allowed" default is the MCP equivalent of granting a user admin on first login. Enumerate the tools the agent requires and deny everything else. When the server adds new tools in the future, existing agents do not inherit access to them automatically — which is the correct default. For a detailed treatment of this scoping model, see Scoping MCP Tool Permissions: Least Privilege for Tools.

Classify tools by sensitivity before granting access. Read-only, write, and destructive tools (delete, send, publish, deploy) represent meaningfully different risk levels. Classify them during discovery and apply tighter controls to higher-sensitivity tiers. Agents should rarely need access to destructive operations without a human approval step.

Require step-up or human approval for irreversible tools. For tools that cannot be undone — deletes, external publishes, financial transactions — consider a step-up enforcement mode where the call is held pending explicit confirmation before it reaches the server. This adds latency to those specific actions, but limits the damage a misconfigured or misdirected agent can cause in a single run.

Tool integrity and supply chain: trusting what the server offers

An allow-list decides which tools an agent may call. It does not tell you whether a tool is what it claims to be.

Vet a server before you register it. Check who publishes it, how it is distributed, what credentials and permissions it asks for, and whether its code is available to review. A community server installed with one command runs with whatever access you give it. The questions to ask are set out in vetting MCP servers from a registry.

Pin versions and review upgrades. A server pulled from a package registry at its latest version can change between two runs of the same agent. Pin the version, and review the changelog and the tool list before you move to a new one.

Read tool descriptions as untrusted input. The model reads each tool's name, description and parameter schema, and a description can carry instructions the user never sees. Review descriptions when you approve a tool, and again when they change. Tool poisoning in MCP walks through the attack.

Compare the tool list with the one you approved. A tool that appears, disappears or changes its description between reviews is drift. Treat a new tool as denied until someone has approved it, and a changed description as a new review.

Inputs, outputs and context: what flows through a tool call

The arguments an agent sends and the results a server returns are where injection happens, in both directions.

Constrain argument values, not only tool names. Allowing a file tool still allows any path. Limit arguments to the values the task needs: one directory, read-only statements, a known set of recipients.

Never build shell commands from model-supplied strings. A server that interpolates an argument into a shell command or an interpreter call turns a prompt injection into code execution. Use parameterised calls and fixed command templates on the server side.

Check results before the agent acts on them. A web page, ticket or email returned by a tool is model input, and it can carry instructions meant for the agent. Screening results for injected instructions and sensitive data limits how far a poisoned document can steer the next call. Detection approaches are compared in how to detect prompt injection.

Share the least context a tool needs. A server does not need the whole conversation, the user's other data or the agent's credentials for unrelated systems. What you do not send cannot leak through that server.

Rate limiting: protecting downstream systems and your own quotas

Rate limits on MCP tool access serve two purposes that look similar but have different owners.

Set per-tool rate limits, not just per-server limits. A server-level rate limit caps aggregate traffic but does not distinguish between a cheap, idempotent read that runs hundreds of times legitimately and a write operation that should be rare. Per-tool limits let you set low thresholds on write and destructive tools without interfering with the read throughput that agents depend on.

Protect upstream API quotas. Many MCP servers wrap external APIs with their own rate limits and metered billing. An agent that retries aggressively or loops on a tool can exhaust your upstream quota or generate unexpected charges. Per-tool limits enforced before the call reaches the server are the first line of defense.

Treat rate limit events as signals, not just blocking mechanisms. A sudden spike in calls to a write or delete tool is worth investigating, not just throttling. Logging rate limit events alongside the agent identity and tool name gives you the data to distinguish a busy-but-legitimate agent from anomalous behavior.

Forensic logging: the record of what actually happened

Every tool call an agent makes through an MCP server is an event worth recording.

Log the tool name, arguments, result, and policy decision for every call. The arguments the agent supplies and the result the server returns are the record of what the agent actually did — not what it was asked to do or what it reported back. Logging both sides of the call is what makes post-incident investigation tractable.

Record policy decisions alongside the call. Whether a call was allowed, denied, or held for step-up is as important as the call itself. An agent that hits a policy denial repeatedly may be misconfigured or attempting something it should not. A forensic record that includes only successful calls is incomplete.

Design for tamper-evidence. A log that can be silently edited after the fact provides limited assurance. Hash-chaining or external anchoring of log records — where each entry commits to the content of the previous one — makes retrospective modification detectable. For compliance contexts where the record needs to hold up to scrutiny, tamper-evidence is a requirement, not a preference.

Apply retention and erasure policies to tool call records. Tool call arguments and results can contain personal data subject to data subject rights. Design your forensic store so records can be queried and erased by subject identifier — otherwise, erasure requests become an operational problem without a clean path.

Inventory, monitoring and health checks: operational visibility

A registered, configured MCP server is not set-and-forget.

Know which servers are in use. Developers can add an MCP server to a local client in minutes, without a review. A server nobody registered gets none of the controls above. Keep an inventory of the servers your agents and developers reach, and look for the ones that are missing from it; detecting shadow MCP servers covers where to look.

Run health checks before agents rely on a server. A health check that probes the server's endpoint and validates that authentication succeeds gives you confirmation that the server is reachable and the stored credentials are current. Running it on-demand before a workflow starts, and on a schedule, catches credential rotation on the provider side before it affects live agents.

Monitor tool-call analytics for usage drift. Call counts, success rates, average latency, and cost per tool give you a baseline. Deviations from that baseline — a tool that was called 10 times a day now called 500 times, or a tool whose latency doubled — are worth investigating before they become incidents.

Toggle server status without deleting the registration. When a server is temporarily unavailable, mark it inactive so agents stop attempting calls rather than deleting and re-registering it, which loses configuration and call history.

Validate the tool list after server updates. An MCP server update may rename, remove, or add tools. Re-running capability discovery confirms the current tool set, surfaces new tools that need explicit authorization decisions, and catches renames that could silently break agent workflows.

How Praesidia supports this checklist

Praesidia's MCP gateway and security capability covers several of these domains for the MCP servers you register:

• Identity per server. Each registered app, agent and MCP server gets its own credentials for authentication and attribution, independent of the humans who deployed it.
• Tool-level authorization. Allow or deny each tool per connection, and constrain the argument values it accepts.
• Tool integrity. Each server is inventoried tool by tool, with drift flagged against the approved fingerprint.
• Inputs and outputs. Guardrails check the arguments and the result of a tool call an agent makes during a chat turn.
• Rate limits. Each tool can carry its own rate limit, and an agent's connection to a server can cap how often it calls each tool. Call volume, success rate, latency and rate-limit hits are shown per tool.
• Forensic logging. Praesidia records the decisions it makes on tool calls in an append-only, hash-chained audit trail, signed under the default configuration; an operator can turn signing off. A call's arguments and result are kept in a separate call log, which is not signed. A signed record shows it was not changed afterwards. It does not show that every action was captured. External anchoring is optional; without it, removal of the most recent records cannot be detected.

Controls apply to servers you have registered, and calls that do not pass through Praesidia are not recorded. How a server handles its own inputs, such as never building shell commands from arguments, stays with whoever runs the server.

The governance model around these controls is in MCP server governance, and what the call metrics show in practice is in How to Monitor MCP Tool Calls.

Common questions

What is the OWASP MCP Top 10?

The OWASP MCP Top 10 is an OWASP Foundation project that lists the most critical security risks for systems built on the Model Context Protocol, from token mismanagement and tool poisoning to shadow MCP servers. At the time of writing it is a beta release, so its entries may still change; the current list is on the OWASP project page.

What is the most important MCP server security control?

Authentication combined with a per-agent tool allow-list. Authentication establishes who is connecting, and the allow-list limits what a connected agent can reach. Together they bound the damage of most other failures, including a poisoned tool or an injected instruction, because the agent can only call the tools it was granted.

Do I need an MCP gateway to secure MCP servers?

Not necessarily. Each control in this checklist can be built into the servers and clients you run. A gateway puts authentication, tool permissions, rate limits and the decision record in one place for many servers, which matters once more than a few teams register servers. What to compare between options is in the MCP gateway comparison 2026.

Do I need all of these controls from day one, or can I phase them in?

Start with authentication and tool-level allow-lists — those two controls together significantly narrow the blast radius of a misconfigured agent. Rate limits and forensic logging are the next priority, giving you visibility before problems escalate. Step-up enforcement and tamper-evident logging can be phased in as workloads grow more complex and compliance requirements become more specific.

What is the right granularity for per-tool rate limits?

Start with a server-level limit as a baseline, then add per-tool limits for the highest-risk tools: write operations, destructive operations, and calls to priced external APIs. Idempotent reads can often share the server-level limit. The goal is explicit, conservative bounds on high-consequence tools, not a limit configured for every tool.

How should I handle MCP servers I do not control — third-party or community-published servers?

Apply the same controls regardless of ownership. For third-party servers, verify the server's identity through a known registration path rather than accepting a self-described endpoint. Tool allow-lists matter more here, since the full tool list may include capabilities appropriate for other users but not for your agents. Prioritize monitoring usage of third-party calls, since you cannot audit the server side directly.