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 operator rule
Threat model the authority, not the prompt.
Prompt injection is the trigger. The blast radius is decided by the tool surface you exposed: paths, networks, tenants, credentials, budgets, side effects, and recovery behavior.
The seven fields
1. Route and capability
Question: Which exact MCP tool or capability is being exposed, and what job is it allowed to complete?
Evidence: Tool name, capability id, allowed input shape, side-effect class, environment, and owner.
2. Caller and trust class
Question: Who is calling, how much autonomy do they have, and should they see this route at discovery time?
Evidence: User, tenant, workspace, agent role, session, trust class, and filtered tool list.
3. Authority surface
Question: What external system, host state, account, network, filesystem, or customer data can the route affect?
Evidence: Allowed host/path/provider/object/resource prefixes plus explicit forbidden neighbors.
4. Credential lane
Question: Which backend principal, BYOK key, vault reference, wallet, managed key, or provider pin is used?
Evidence: Credential mode, scope, expiry/rotation behavior, revocation path, and owner.
5. Budget and quota owner
Question: Who pays for retries, provider calls, x402 proofs, quota burn, and partial success?
Evidence: Estimate, cost ceiling, quota bucket, retry ceiling, idempotency key, and billing owner.
6. Denied neighbor
Question: What nearby action must fail before the route can be called production-ready?
Evidence: A fixture for sibling path, private IP, wrong tenant, larger amount, write variant, or off-policy provider.
7. Receipt and recovery
Question: Could an operator reconstruct what happened without re-running the agent conversation?
Evidence: Policy decision, normalized input, denial reason, provider outcome, retry state, cost, and recovery hint.
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
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:
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.
Common failures
- 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.