MCP Threat-Model Checklist

An MCP server hands an AI agent real tools and real access. It deserves a threat model before it touches anything that matters. This is the reusable version of the STRIDE walk-through from Threat-Modelling Your First MCP Server: eighteen questions across the six letters. Tick each one only when you can defend the answer out loud. Budget an afternoon per server.

Prefer a document? Download the Markdown template for the same checklist plus the data-flow sketch, tool blast-radius table, and sign-off block.

0/18

Progress is saved in your browser only. Nothing leaves this page.

SSpoofingCan something pretend to be a trusted party?

Could a malicious server impersonate this one in the agent's tool list (name collision, typosquat)?
Does the server authenticate which client/agent is calling, or serve anyone who connects?
Are its upstream credentials a distinct identity (not shared with humans or other services)?

TTamperingCan inputs, tools, or results be altered?

Have we read every tool description as prompt context? Could one steer the agent?
Are tool definitions pinned, with alerts on change?
Is transport integrity (TLS) enforced end to end?

RRepudiationCan an action happen with no reliable record?

Is every tool call logged with name, arguments, result, and invoking user?
Could we reconstruct which request and context led to a destructive action?
Do those logs land in central telemetry (not just local stdout)?

IInformation disclosureCan data escape its boundary?

Does this server complete the lethal trifecta (private data + external reach + untrusted content)?
If yes: which leg have we cut, and how?
Is network egress from tool execution default-deny / allow-listed?

DDenial of serviceCan it be made unavailable or ruinously expensive?

Are tool calls rate-limited and budget-capped (tokens, API spend, downstream quotas)?
Do slow or hanging tools time out instead of stalling the agent?

EElevation of privilegeCan the agent do more than intended?

Does every tool scope match the actual use case (no write/delete where read suffices)?
Can chained calls compose into an action no single tool was meant to allow?
Is the agent's authority bound to the invoking user (never more than that user alone)?
Have we listed the irreversible actions that require a human approval gate?

The one question that decides it:

“If a malicious instruction reached this agent through the data it reads, what's the worst tool it could reach, and have I gated that?”