The MCP server security checklist we run before handoff.

A traditional API is called by code you wrote, with inputs you control. An MCP server is called by a model, based on natural language it was given, which may include text from an untrusted source, a customer email, a scraped webpage, a support ticket. That means the caller's intent is only as trustworthy as whatever text influenced the model's decision to call the tool. This is the core reason MCP security can't just borrow API security wholesale.

We cover the foundational mechanics of the protocol in our MCP explainer and the build process itself in our MCP server development guide. This post is specifically about the security layer that sits on top of a working server.

The common advice is "put OAuth in front of your MCP server and you're covered." OAuth is necessary and most teams should have shipped it months ago, but it answers only one question: is this caller who they claim to be. It doesn't answer the questions that actually cause incidents: can this authenticated caller's agent be tricked into calling a tool it shouldn't, can it read another tenant's data through a scoping bug, and does the tool's own description contain something that manipulates the model's behavior. Authentication is table stakes. Authorization scoping, argument validation, and tool-definition integrity are the parts that actually stop the damage once something goes wrong upstream of the tool call.

1. OAuth or an equivalent token-based auth, no shared static API keys embedded in prompts or config files.
2. Short-lived tokens with refresh flows, not long-lived credentials that outlive an employee's access.
3. Per-user or per-session identity carried through to every tool call, not collapsed into one service account.

1. Row-level and tenant-level scoping enforced at the server, never trusted from the prompt or the model's stated intent.
2. Least-privilege tool permissions, each tool scoped to the minimum data and actions it needs, not a shared "admin" credential reused across tools.
3. Explicit deny by default for any action outside a tool's documented scope, rather than allowing anything not specifically blocked.
4. Cross-tenant test cases run before launch, deliberately trying to access another tenant's data with a valid but wrong-scoped session.

1. Typed inputs with schema validation on every tool, rejecting malformed or unexpected argument shapes before execution.
2. Boundary and injection testing on arguments, including attempts to pass instructions or code where plain data is expected.
3. Typed, schema-validated outputs returned to the model, so a compromised downstream system can't inject arbitrary text back into the model's context unchecked.
4. Rate limits and quotas per tool, so a manipulated agent can't loop a costly or destructive action.

This is the same discipline behind treating agentic behavior as something that needs guardrails proportional to its autonomy, not proportional to how impressive the demo looked.

1. Pin and version tool definitions rather than pulling live descriptions from a source you don't control on every call.
2. Review tool descriptions like code, since a model reads them as instructions, and a subtly manipulated description is a viable attack vector, sometimes called tool poisoning.
3. Restrict which servers an agent can discover and connect to, rather than allowing arbitrary MCP server discovery in production.

1. Approval queue for irreversible or high-blast-radius actions, like payments, deletions, or external communications sent on a customer's behalf.
2. Reversibility check for every write tool: can this be undone automatically if the model got it wrong.
3. Escalation path defined for when a tool call fails validation or looks anomalous, rather than silently retrying or failing open.

1. Every tool call logged with caller identity, arguments, result, latency, and cost, piped into your existing observability stack.
2. Alerting on anomalous call patterns, like a spike in a normally rare tool or repeated failed argument validations.
3. Logs retained long enough for a real incident review, not just a rolling 24-hour window.

Fourteen checks total, and we run all of them before handoff on every Anthropic consulting engagement that involves an MCP server, because a tool surface without this review is a liability wearing a demo.

If your MCP server is already in production and you haven't run through this list, don't wait for an incident to force the review. Start with authentication and tenant scoping, since those two categories cause the most damage when they fail. Then work down the list over one or two sprints. If you want an outside set of eyes to run the full checklist against your specific server, that's exactly the kind of thing we scope in the $1,000 AI Audit.