How do you secure an MCP server?

Authenticate every request and authorize each tool call against the specific caller; give each tool the narrowest scope that does its job; keep credentials in the server, never in a tool response; validate all tool inputs against a schema; require human approval on state-changing actions; and log every call to an immutable audit trail. Then test it by running the tools as both an authorized and an unauthorized caller and diffing the results.

Guide · September 24, 2026 · 10 min read

MCP server security: risks and a checklist.

Q: What are the main MCP server security risks?

Four dominate: prompt injection riding inside the data a tool returns; over-broad tool scopes that let an agent do more than intended; credential exposure when a server hands raw API keys to the model instead of holding its own scoped credential; and unbounded or irreversible actions with no human approval. All four are amplified because the model treats retrieved content as trusted unless the server is designed not to.

Q: Is prompt injection a real risk for MCP servers?

Yes. Any content a tool returns — a document, a ticket, a record an account can write to — is untrusted input the moment it reaches the model. Instructions hidden in that content can steer the agent into calling other tools. The defense is architectural: scope tools tightly, never let the model compose privileged operations freely, and gate writes behind human approval, so an injected instruction cannot cause an irreversible action on its own.

The failure modes that actually get MCP servers into trouble — and the controls that close them before one touches a system of record.

The short answer

Four risks dominate MCP server security: prompt injection hidden in the data a tool returns, over-broad tool scopes, credential exposure when a server hands raw keys to the model, and unbounded actions with no human approval. The fixes are architectural, not a better prompt: scope tightly, authorize per caller, keep credentials in the server, validate inputs, gate writes behind a human, and audit everything.

The MCP threat model in one picture

An MCP server sits between a model and your systems and exposes tools the model can call. The security problem follows from one fact: the model is not trusted, and neither is the data your tools return. Content a tool fetches — a document, a ticket, a record an account can write to — becomes part of the model's context, and a model will act on instructions embedded in it. So the server, not the model, has to be the thing that enforces what is and isn't allowed. If that framing is new, start with what is an MCP server, then come back.

The four risks that actually bite

Prompt injection through tool data. The highest-frequency risk. An instruction hidden in a document or record the agent reads can steer it into calling other tools. You can't prompt your way out of this — the defense is to scope tools so an injected instruction has nothing dangerous to reach.
Over-broad scopes. A tool that wraps "run any query" or holds admin permissions turns one compromised call into full access. Each tool should expose the narrowest operation that does the job.
Credential exposure. Handing the model a raw API key, or returning secrets inside a tool response, leaks them into logs, context windows, and transcripts. The server holds its own scoped credential; the model never sees it.
Unbounded and irreversible actions. A tool that deletes, transfers, or emails with no ceiling and no approval is one hallucination away from an incident. State-changing actions need a human in the loop and hard limits.

The hardening checklist

☐ Authenticate every request before dispatching any tool
☐ Authorize each tool call against the specific caller's access (two identities: the server's and the caller's)
☐ Give each tool the narrowest scope that does its job
☐ Keep credentials in the server — never in a tool response or the model's context
☐ Validate every tool input against a schema before use
☐ Separate read tools from write tools; gate every write behind human approval
☐ Set limits and timeouts so one caller can't exhaust the backend or run an unbounded operation
☐ Log every call — caller, tool, arguments, outcome — to an immutable audit trail
☐ Version tools so you can change one without breaking connected clients

This is the same posture we deliver on MCP security engagements, and bake in from day one on MCP server development.

How to test that it's actually safe

A checklist you never test is a wish list. The single most valuable test for an MCP server is a permission diff: run your full tool suite twice — once as a fully authorized caller, once as a caller outside the relevant boundary — and diff the results. Any fact, count, or confirmation that appears in both runs and shouldn't is a leak, and it should fail the build. Add a fixture that contains a deliberately planted injection string, and assert that the agent does not call a privileged tool because of it. Those two tests catch the failures that survive ordinary QA precisely because nothing errors.

Frequently asked questions

What are the main MCP server security risks?

Prompt injection through tool data, over-broad tool scopes, credential exposure, and unbounded or irreversible actions — all amplified because the model treats retrieved content as trusted unless the server is designed not to.

Is prompt injection a real risk for MCP servers?

Yes. Any content a tool returns is untrusted input the moment it reaches the model. The defense is architectural: scope tools tightly, never let the model compose privileged operations freely, and gate writes behind human approval.

Keep reading

Guide