← Blog · MCP security · May 16, 2026

Threat model template

MCP threat modeling starts with one tool call.

A production MCP threat model should be small enough to run before the agent repeats a call. If you cannot name the route, caller, authority surface, credential lane, denied neighbor, budget owner, and receipt, the tool is not ready for unattended use.

Fast answer

→An MCP threat model is not a list of scary things the model might say. It is a route-by-route contract for what a tool can touch when the model is wrong.
→Start with one tool call, then bind caller, trust class, authority surface, credential lane, data boundary, spend boundary, denied neighbor, and receipt fields before production traffic repeats it.
→Treat filesystem, fetch/browser, repo, CRM, payments, email, and deployment tools as different authority classes. A read-only label is not enough when the tool can reach host state, private networks, customer records, or billable side effects.
→The useful output is a copy-paste route card plus negative fixtures: the adjacent file, URL, tenant, amount, provider, row, or side effect that must fail closed.

The seven fields

Route and capability

Which exact MCP tool or capability is being exposed, and what job is it allowed to complete?

Tool name, capability id, allowed input shape, side-effect class, environment, and owner.

Caller and trust class

Who is calling, how much autonomy do they have, and should they see this route at discovery time?

User, tenant, workspace, agent role, session, trust class, and filtered tool list.

Authority surface

What external system, host state, account, network, filesystem, or customer data can the route affect?

Allowed host/path/provider/object/resource prefixes plus explicit forbidden neighbors.

Credential lane

Which backend principal, BYOK key, vault reference, wallet, managed key, or provider pin is used?

Credential mode, scope, expiry/rotation behavior, revocation path, and owner.

Budget and quota owner

Who pays for retries, provider calls, x402 proofs, quota burn, and partial success?

Estimate, cost ceiling, quota bucket, retry ceiling, idempotency key, and billing owner.

Denied neighbor

What nearby action must fail before the route can be called production-ready?

A fixture for sibling path, private IP, wrong tenant, larger amount, write variant, or off-policy provider.

Receipt and recovery

Could an operator reconstruct what happened without re-running the agent conversation?

Policy decision, normalized input, denial reason, provider outcome, retry state, cost, and recovery hint.

Authority classes

Every MCP tool is not the same kind of risk.

The mistake is to evaluate tools by whether they are read or write in natural language. Evaluate them by what authority they can exercise when a planner picks the wrong argument.

Filesystem / repo

Risk: Host-state authority disguised as a local helper.

Fixture: Allow one canonical repo prefix; deny parent traversal, symlink escape, hidden config, sibling repo, and host mount.

Fetch / browser / crawl

Risk: Network egress that can touch cloud metadata, loopback, private subnets, and internal services.

Fixture: Resolve DNS before request; deny metadata, loopback, RFC1918, IPv6 ULA, current-network, and service-network targets.

CRM / ticketing / docs

Risk: Tenant and record authority hidden behind friendly search or update verbs.

Fixture: Allow one workspace/object lane; deny another tenant, private project, archived record, and broad export.

Payments / billing

Risk: Budget authority where retries and partial success become real money.

Fixture: Allow one amount/merchant/product lane; deny higher amount, duplicate idempotency key, and unpriced provider path.

Email / messaging

Risk: External communication authority that can impersonate intent or leak data.

Fixture: Allow draft or approved recipient class; deny external send, list blast, wrong account, and hidden attachment.

Deploy / CI / infra

Risk: Change authority where one tool call can mutate production state.

Fixture: Allow read/build/status first; deny deploy, secret read, privilege escalation, and unreviewed config mutation.

Copy-paste route card

The threat model should fit in a route card.

A route card is useful because it forces the security conversation out of abstractions. If the card cannot be filled out, the runtime will improvise under pressure.

Route / MCP tool:
Workflow job:
Caller / tenant / workspace:
Trust class:
Allowed authority surface:
Forbidden neighbors:
Credential lane / backend principal:
Budget owner / quota bucket:
Retry and idempotency rule:
Denial fixture that must fail closed:
Receipt fields required for audit:
Recovery path when the call is denied, partial, or duplicated:

Common failures

Most MCP security failures are threat-model omissions.

Discovery shows tools the caller is not allowed to use, so the model plans around impossible authority.

A parameter accepts arbitrary strings where the runtime needed normalized path, host, tenant, amount, or provider allowlists.

Auth proves identity but the backend principal is shared across tenants or workflows.

A denied neighbor returns a generic 500, silent retry, or partial side effect instead of a typed denial.

Receipts log the final provider response but omit the policy decision, credential lane, normalized input, and cost owner.

The test suite covers the happy path and never runs the adjacent path, private IP, wrong tenant, larger spend, or unsafe write variant.

Related operator guides