Step 1 of 4
Inventory assets and entry points
Threat modeling starts with what is worth protecting and how it is reached.
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.
Expected after this step
An inventory of assets and entry points with authority and reach.
Should not happen
- ✕Shipping an MCP server with no analysis of what it exposes
- ✕Trusting the calling agent implicitly despite injection risk upstream
- ✕Threats listed but never mitigated or tested
- ✕No record of accepted residual risk, so gaps are forgotten
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Shipping an MCP server with no analysis of what it exposes
- !Trusting the calling agent implicitly despite injection risk upstream
- !Threats listed but never mitigated or tested
- !No record of accepted residual risk, so gaps are forgotten
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The inventory assumes only a trusted local agent calls it. Even a local agent can be injection-driven - and if the transport is or could become networked, the surface is far larger; model the realistic worst case, not the demo setup.