How to Secure an MCP Server (Tutorial)

Quick answer
Secure an MCP server the way you’d secure any privileged service: least-privilege tools, authenticated connections, and scoped credentials.
Never run a server with standing admin credentials.
Gate high-impact tool calls behind human approval, because prompt injection can make the model request them.

What you’re securing

An MCP server is a program that exposes tools to an AI client. “Securing” it means controlling three things: who can connect, what tools they can call, and what credentials those tools act with. The goal is that even a compromised or manipulated model can only do a limited, auditable amount of damage.

Step 1 — Scope tools to the minimum

Expose only the specific operations the workflow needs. If the assistant should read tickets but not delete them, the server must offer a read tool and no delete tool. The tool list is your authorization surface: anything not on it is unreachable.

How to verify it worked: the model cannot perform any action you didn’t explicitly expose, even when asked.

Step 2 — Authenticate the connection

Don’t expose an MCP server on a network with no authentication. Require a token or mutual TLS between client and server, and use the least-privileged identity for the connection itself.

How to verify it worked: an unauthenticated client gets a rejection, and the server logs the denied attempt.

Step 3 — Use scoped, short-lived credentials

Instead of handing the server a long-lived admin key, use a credential with a narrow scope and short lifetime — a temporary token, a role limited to one resource, or a just-in-time grant.

How to verify it worked: the credential can access only its intended resource and stops working when it expires.

Step 4 — Gate high-impact actions

Wrap destructive or sensitive tool calls (writes, sends, deletions, payments) in a human approval step. The model requests the action; a person confirms it before it executes.

How to verify it worked: a high-impact request pauses for approval instead of executing immediately.

Step 5 — Log and review

Record every tool call with the requesting context. Logs are how you notice a model being steered into unusual actions — the signal that something is wrong.

Where this bites vibecoders
The convenient default — “give the assistant full access so it just works” — is the insecure default. An AI coding assistant generating an MCP server will not add auth or scoping unless asked. Security here is a checklist you impose on the convenience, not something the tool will do for you.

Where AI coding assistants get this wrong

Exposing full CRUD tools when read-only would do.
Embedding long-lived admin keys in the server configuration.
Running the server unauthenticated on a local network or public endpoint.
Omitting any approval step for destructive actions.

Checklist

Expose the minimum tool set for the workflow.
Authenticate client-server connections.
Use scoped, short-lived credentials, never standing admin keys.
Require human approval for destructive or sensitive actions.
Log every tool call and review for anomalies.

FAQ

What is the biggest MCP mistake?

Running the server with standing, over-broad credentials and exposing more tools than needed. Combined with prompt injection, that means a single malicious document can trigger a real destructive action. Scope and short-lived credentials are the two highest-impact fixes.

Does authentication protect against prompt injection?

No. Authentication controls who connects; it doesn’t stop a legitimate connection’s model from being steered by injected content. That’s why tool scoping and human approval are separate, essential controls.

Should I run third-party MCP servers?

Only ones you’ve audited, and with the same least-privilege rules. A third-party server runs with whatever credentials you give it, so treat it as untrusted code with the permissions you assigned.