Threat-Model Your MCP Server
Systematically threat-model an MCP server before it is exploited: assets, entry points, trust boundaries, and mitigations documented and tested.
The route
4 steps to Done
- 01
Inventory assets and entry points
Threat modeling starts with what is worth protecting and how it is reached.
Preview prompt + verify gate ▾ Hide ▴
Document the server's assets and entry points. ASSETS: everything the server can read (files, databases, APIs, secrets), write/mutate (filesystem, records, external calls), and the server process/host itself. ENTRY POINTS: each exposed tool (with its capability), the transport (stdio/local vs networked - networked massively expands the surface), the initialization/discovery interface, and any configuration inputs. For each entry point note the authority it wields (what it can touch) and who can reach it. Explicitly record the trust reality: the calling agent may be acting on injected instructions from untrusted content, so the server cannot assume its caller is benign. Deliver the asset+entry-point inventory.
- ✓ Read/write/host assets enumerated
- ✓ Transport and its exposure noted
- ✓ Caller-not-trusted reality documented
- 02
Map boundaries and enumerate threats
Structured enumeration beats imagination for coverage.
Preview prompt + verify gate ▾ Hide ▴
Map trust boundaries and enumerate threats. Draw the boundaries: untrusted content -> agent -> MCP client -> transport -> your server -> its assets. At each boundary apply a structured method (STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) and list concrete threats for THIS server: e.g. a tool coaxed (via injection upstream) into reading a file outside its intended scope (information disclosure), argument tampering to reach unintended records, a slow/large request exhausting the server (DoS), a tool whose output leaks internal paths or secrets, elevation via a tool that is more powerful than its description implies. Produce the threat list tied to specific tools and boundaries.
- ✓ Boundaries drawn end to end
- ✓ STRIDE (or equivalent) applied per boundary
- ✓ Threats tied to specific tools
- 03
Rank threats and assign mitigations
Finite effort goes to the threats that matter most.
Preview prompt + verify gate ▾ Hide ▴
Rank and plan. Score each threat by impact (what is lost if it succeeds) and likelihood (reachability given the trust reality), producing a ranked list. Assign a mitigation to each high/medium threat, drawing on the standard MCP-server controls: strict input validation and path canonicalization (scope every file/resource access to an allowed root; reject traversal), least-privilege tool design (each tool touches only what it must; split over-powerful tools), output filtering (scrub secrets/internal paths from results), resource limits and timeouts (DoS), authentication/authorization on networked transports, and audit logging of every call. Map mitigation -> threat -> owner. Explicitly mark any threat you will accept rather than mitigate, with justification.
- ✓ Impact x likelihood ranking done
- ✓ Standard MCP controls mapped to threats
- ✓ Accepted risks justified explicitly
- 04
Implement, test, and record residuals
A threat model is a plan until the mitigations exist and are proven.
Preview prompt + verify gate ▾ Hide ▴
Execute the mitigations and verify. Implement the high-rank mitigations: e.g. canonicalize and confine every path argument to an allowed root (test with traversal payloads: ../, absolute paths, symlinks); enforce least privilege (test that each tool cannot reach out-of-scope assets); filter outputs (test that a result cannot contain secret patterns or host paths); add resource limits (test with an oversized/slow request); add audit logging (verify every call is recorded). Each mitigation gets a targeted security test that attempts the threat and asserts it is blocked - add these to CI. Finally, write the residual-risk register: what remains unmitigated, why it was accepted, and what would change the decision. Review the completed threat model against the running server.
- ✓ Path confinement tested against traversal
- ✓ Each mitigation has a threat-attempting test
- ✓ Residual risks registered and accepted
Research-backed