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.
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.
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.
Monitoring and health checks: operational visibility
A registered, configured MCP server is not set-and-forget.
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 is designed to support this checklist
Praesidia is designed to address each of these layers as part of the standard registration and connection flow. Credentials are encrypted at rest. Tool-level authorization is enforced at a policy gate before each call reaches the server, with configurable allow/deny/step-up/observe modes per tool. Per-tool rate limits are configurable independently of server-level controls, and every tool call is recorded in a forensic store that captures the policy decision, arguments, result, and estimated cost.
Health checks and capability discovery are first-class operations, and tool-call analytics aggregate call history into usage metrics that make drift visible over time. The objective is to maintain the posture described in this checklist at the platform level rather than reassemble it per-agent and per-server.
You can review how the platform structures MCP server governance in Registering and Governing MCP Servers, or see how tool call monitoring works in practice in How to Monitor MCP Tool Calls.
Common questions
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.