Start with the job: threat-model an MCP integration before granting access

MCP security starts with consequences, not with whether a connection succeeds. Inventory what the server can read, what its tools can change, which untrusted content enters the model context and where credentials cross trust boundaries.

Protocol conformance does not make a server trusted. Authentication identifies parties and authorization constrains access, but prompt injection, excessive scope, token mishandling and unsafe downstream actions still require system controls.

Keep this page's decision boundary canonical

Threat-model the real integration rather than an abstract protocol. This cluster owns assets, entry points, capability consequences and layered controls. Authorization and prompt-injection pages handle their narrower mechanisms, while server pages supply product-specific permission evidence. The reader should leave with an explicit residual-risk decision: which calls are allowed automatically, which require review, what remains isolated and which connection must not be made.

Separate confidentiality, integrity and external-action consequences in the review. A read-only server may still expose private data to a model or remote service; a low-sensitivity tool may still change a public system. Labeling an integration simply read or write therefore misses combinations that need different containment. For every capability, record data classification, recipient, action target, reversibility and whether the host can preview exact parameters before execution.

Operational controls should survive model failure. Credential scopes, network policy, sandboxing, downstream authorization and rate limits must constrain the call even when the model follows an injected instruction. Approval is strongest when the reviewer sees the actual target and parameters, and weakest when it asks for broad confirmation before the agent decides what to do. Pair controls with monitoring that can attribute a call to server, user, workflow and credential without persisting sensitive content unnecessarily.

Make the operating boundary visible

Risk travels along a chain: content enters through resources or tool results, influences an agent decision and may reach a tool with external side effects. Layered controls break that chain through data separation, narrow scopes, approval, validation and containment.

FIG. 01 / Conceptual model

From untrusted content to consequence

Threat trace from MCP content through an agent decision to a privileged tool
Conceptual model: risk becomes consequential only when untrusted content can influence a privileged action path.

Build a reproducible path

For MCP Security: Threat Model Before Connection, use a small fixture that another developer can repeat without privileged production data. Change one boundary at a time and preserve the exact configuration needed to explain how the page's decision was reached.

  1. Classify every input as trusted configuration or untrusted data.
  2. Map each capability to reachable data and external side effects.
  3. Bind credentials to the intended server and minimize their scopes and lifetime.
  4. Test approval, denial, revocation and audit behavior with controlled adversarial inputs.

Keep secrets outside the mcp security artifact. Record variable names, scopes and owners, then verify the relevant system of record whenever this tool or workflow can change external state.

Record evidence that survives a rerun

The threat model should connect an asset to an entry point, a capability and a consequence. Generic warnings about AI are not actionable without the exact server, tool, credential and downstream system involved.

  • Protected data and consequential actions
  • Untrusted content sources and model context path
  • Token audience, storage and rotation owner
  • Approval event, audit record and containment boundary

Date the MCP Security: Threat Model Before Connection record and keep factual observations separate from inference. If a claim depends on a hosted service, preview feature or moving SDK, name that dependency beside the claim.

Use a decision rule and a stopping rule

Permit a connection only when the remaining consequence is acceptable after controls, not merely when a prompt refuses a test string. High-impact write or communication actions need stronger isolation and explicit approval than read-only, low-sensitivity retrieval.

Exercise both direct and indirect instructions using non-production fixtures. Confirm that disallowed calls never reach the downstream system, that allowed calls retain the intended parameters and that credential revocation terminates access.

FIG. 02 / Decision aid

Controls by action impact

Decision matrix matching MCP capability impact with isolation and approval controls
Decision aid: stronger consequence demands narrower scope, clearer approval and better containment.

Protect against predictable failure and continue deliberately

For MCP Security: Threat Model Before Connection, the architecture review flags three recurring failure modes: specification versions are mixed; local and remote trust boundaries are conflated; a server is recommended without permission review. Treat them as release checks, not footnotes. This page remains draft when its exact implementation or intent evidence is still research-gated.

Use the MCP field guide next: it reconnects the decision to protocol roles and versioned boundaries.

Use the MCP authorization guide next: it covers resource-bound tokens, validation and upstream separation.

Use the MCP prompt-injection model next: it shows how untrusted content can reach consequential tools.

Use the MCP server evaluation guide next: it shows how to screen ownership, capabilities and access before connection.