How to secure an MCP server: auth, tool allowlists and prompt injection

Why MCP servers end up exposed and unprotected

Model Context Protocol (MCP) servers give an AI agent the ability to call real tools — reading files, querying a database, hitting an internal API — which is exactly what makes an unprotected one dangerous. According to the Model Context Protocol specification, “the protocol intentionally limits server visibility into prompts” and places a strong emphasis on user consent for tool invocation and data access, but authorization itself is explicitly optional in the spec — implementations using an HTTP-based transport “SHOULD” support it, not “MUST.” That gap between “should” and a hard requirement is exactly where many real-world MCP servers end up: built quickly during a prototype, left reachable on the public internet, with no authentication layer added before anyone noticed.

Step 1: find out what you’ve actually exposed

Before hardening anything, check your current state. AdminKit’s MCP endpoint check tests whether an MCP endpoint is reachable and whether it demands authentication, which answers the most urgent question first: is this server callable by anyone who finds it right now. If it’s meant to be internal-only, confirm it isn’t reachable from the public internet at all before worrying about anything further down this list.

Step 2: implement authorization per the spec, not an ad-hoc scheme

The MCP Authorization specification defines a complete OAuth-based flow for HTTP-transport MCP servers, built on existing, well-reviewed standards rather than a custom scheme:

• Your MCP server acts as an OAuth 2.1 resource server, validating bearer tokens on every request.
• It must implement OAuth 2.0 Protected Resource Metadata (RFC 9728) so clients can discover which authorization server to use.
• The authorization server itself must publish OAuth 2.0 Authorization Server Metadata (RFC 8414).
• Servers should support Dynamic Client Registration (RFC 7591) so clients can obtain credentials without manual, per-client setup — important for MCP specifically, since a client may encounter servers it has no prior relationship with.
• On an invalid or missing token, the server must return HTTP 401 with a WWW-Authenticate header pointing to its resource metadata — this is how a well-behaved client discovers how to authenticate in the first place.
• Tokens must be validated for audience (that they were actually issued for this server) — the spec is explicit that a server “MUST NOT accept or transit any other tokens,” specifically to prevent a stolen or misdirected token issued for one service being replayed against another.

This is more involved than typical API-key auth, but reusing standard OAuth 2.1 flows (described in RFC 6749 and refined since) means you can lean on existing, well-tested OAuth libraries rather than building token validation from scratch.

Step 3: add a tool allowlist, separate from authentication

Authentication answers “who is this caller.” A tool allowlist answers a different question: “which of my tools should this caller be able to invoke at all.” These are not the same control, and skipping the second one is a common gap even on servers that do authenticate properly:

• Enumerate every tool your server exposes and explicitly decide whether it should be callable by external clients at all — development or debug tools are frequently left callable by accident.
• Where your MCP framework supports scoped tokens, tie specific tools to specific OAuth scopes, so a token issued for read-only access literally cannot invoke a tool that writes data.
• Log every tool call (who, which tool, when, and the outcome) — this is what makes it possible to notice misuse after the fact, not just block it in the moment.

Step 4: treat tool responses as untrusted input

This is the step most MCP deployments miss entirely. The OWASP Top 10 for LLM Applications lists Prompt Injection as its top risk (LLM01), and tool responses are a direct, realistic injection path: if a tool fetches content from an external, untrusted source (a webpage, a user-submitted file, a third-party API) and that content contains text crafted to look like instructions, a model reading that response as part of its context can be manipulated into acting on those embedded instructions instead of the user’s original request.

Practical mitigations, used together rather than any one alone:

• Never treat tool output as trusted instructions. Structure prompts so the model is told tool results are data to evaluate, not commands to follow.
• Filter or flag suspicious patterns in tool responses before they reach the model — text that resembles system-prompt-style instructions embedded in otherwise ordinary data is a common red flag.
• Require explicit confirmation for consequential actions. The MCP specification’s own security principles state that “Hosts must obtain explicit user consent before invoking any tool” — extend that same caution to acting on anything a tool response suggests doing next, not just the initial call.
• Keep an audit trail of tool calls and responses so an unusual pattern can be investigated after the fact.

Step 5: re-check regularly, not just once

An MCP server’s exposure can change without anyone touching its code — a network change, a new deployment, or a forgotten debug build can all reintroduce the same gap you just closed. Re-run MCP endpoint check periodically, and if you’re exposing TLS (which you should be, for any server reachable outside a trusted network), confirm your certificate setup with SSL/TLS check too.

Where AdminKit fits

AdminKit’s planned MCP & Agent Gateway is designed to sit in front of an MCP server and apply OAuth enforcement, tool allowlists, and response filtering as a managed layer, with an audit log of every call — useful if you’d rather not build and maintain all of the above yourself. The planned Agent Trust API addresses the other side of the same problem: letting an agent check an unfamiliar endpoint before calling it, instead of calling first and finding out later. Neither is live yet; both are in early access and development, so the steps above remain the practical path today. See our AI agent builders page for the fuller picture of what’s free now versus planned.