How to Secure an MCP Server: 10 Steps

Scope the credential first

Reduce the credential the server holds on its backing system to the narrowest permission the use case needs. A server built to look up orders should hold a read-only role on the orders table — not a database user that can also update and delete, however convenient that was during development.

This step is first because it is the only one that shrinks the worst case rather than reducing the chance of reaching it. Every other control on this list is a filter in front of a capability; if the capability is gone, the filter cannot fail open. Expect this to be the step that requires the owner’s agreement and takes the longest in calendar time.

Authenticate every caller

Require a short-lived, verifiable token per calling agent and validate it on every request, not just at connection. A static shared key in a client config proves only that someone holds the key: you cannot attribute a log line to an actor, revoke one caller, or rotate without breaking all of them at once.

Preserve the original caller’s authority rather than collapsing everyone into one service account — otherwise a low-privilege user’s request executes with the service account’s privileges, which is the confused-deputy problem with a protocol in the middle. MCP authentication patterns compares what each option actually proves.

Expose the fewest tools that work

Delete the tools nobody calls. Split read tools from write tools into separate servers with separate credentials, so a read-only deployment cannot be persuaded into mutating anything regardless of what reaches the model. Then filter the tools/list response by caller identity.

Filtering discovery matters more than it sounds. A tool the model never learns exists cannot be talked into existence by injected content, and a shorter tool list also measurably improves the model’s selection accuracy. Security and quality point the same way here, which is rare enough to use as an argument.

Bound every parameter

Validate against a schema with real limits: amount ceilings, allow-listed recipients, row caps, date ranges, enumerated values. A transfer tool with no maximum is a different tool at 10 and at 10 million, and tool-level permission alone cannot tell those apart.

Reject out-of-range values rather than silently clamping them — a clamp hides the attempt, and the attempt is the signal you want in the log. Never build SQL, shell commands or file paths by concatenating model-supplied strings. The values arriving here were produced by something that can be persuaded, so they get the same treatment as input from the public internet.

Treat tool output as untrusted input

Whatever your server returns flows back into the model’s context, where it competes with your instructions. If any of it originates outside your control — a support ticket, a web page, a document, a field a customer can type into — assume it may contain instructions aimed at the model.

Strip or neutralise control markup, label the boundary between data and instruction explicitly, and cap response size so one call cannot flood the window and push your system prompt out of effective range. This does not solve indirect prompt injection — nothing at the server level does — but it removes the cheapest version of the attack.

Require approval for irreversible calls

List the tools that move money, delete data, change access or are visible outside the company, and hold those calls for a human decision. The test is not how sensitive the system feels but whether the action can be taken back: an email sent to a customer is irreversible in a way a database read never is.

Show the approver the tool, the parameters and the calling identity — not a generic “allow this action?” prompt. An approver who cannot see what they are approving becomes a rubber stamp within a week, which is worse than no approval because it manufactures a record of oversight that did not happen. Designing approval thresholds covers where to draw the line.

Rate-limit per identity

Ceilings per agent, per minute and per day, plus a spend ceiling wherever calls cost money. The most common MCP incident is not an attack — it is an agent in a retry loop calling the same tool ten thousand times, and without a per-identity limit that is indistinguishable from abuse until the invoice or the rate-limit response from the backing system arrives.

Limit per identity rather than per server, or one runaway agent consumes the budget of every well-behaved one. Agent spend ceilings goes into the cost side.

Log every attempt, including refusals

One structured record per invocation: caller identity, tool, parameters, policy decision, approver where applicable, result status and timestamp. Write it where the decision is made, and send it somewhere the security team can query without asking an engineer to grep a container.

Refusals are the more valuable half. A successful call tells you the system worked; a rising refusal rate against one tool tells you either your policy is wrong or an agent is being steered, and both are things you want to notice early. Redact secrets at write time — a log that has to be sanitised before anyone may read it is a log nobody reads. How to audit AI agent actions covers the record in detail.

Isolate the runtime

Non-root user, its own container, no inbound network beyond the client port, egress restricted to the systems it legitimately calls, secrets injected at runtime rather than baked into an image or read from a file on a developer’s laptop, and a pinned dependency set you can rebuild reproducibly.

Egress restriction is the item most often skipped and the one that most limits damage: a server that can only reach its own backing system cannot be used to move data somewhere else, whatever it is persuaded to attempt.

Verify by attempting what should fail

Controls that have never refused anything are assumptions. Write tests that expect refusal and assert the refusal reaches the log — the five below take an afternoon and then run on every deploy, which is what stops a refactor quietly widening what an agent can reach.