Mcp Risk Boundaries — Claude Code Guide

MCP has four risk boundaries

MCP risk is easier to review when separated into data exposure, action capability, source reliability, and operational failure. A server can be read-only yet still expose sensitive data or return misleading context.

Boundary	Review question
Data	What information enters context or logs?
Actions	What can the tool change or launch?
Trust	How is returned information verified?
Failure	What happens when the server times out or disagrees?

Keep facts and actions separate

Treat issue text, alert text, and docs as input, not instruction.
Confirm identifiers and version before relying on external data.
Translate a signal into a local task specification.
Require explicit approval for comments, status changes, merges, deploys, and destructive operations.
Keep a manual fallback and a disable path.

Risk review record

Documented MCP boundary record

# MCP risk review

Server: <name>
Data read: <fields>
Writes: none / <explicit list>
Sensitive data: <boundary>
Verification source: <code, docs, or test>
Failure fallback: <manual path>
Kill switch: <disable step>
Status: documented example; external outcome: Unknown.

Stop conditions

Stop when a write operation is not explicitly required.
Stop when credentials or sensitive fields cannot be bounded.
Stop when returned facts conflict with local evidence.
Stop when the server lacks a disable or fallback path.
Stop before external side effects until the owner decides.