MCP security — authorize each identity and tool
Model Context Protocol standardizes an integration surface; it does not make a server, tool, or returned value trustworthy. Security depends on the concrete data flow and authority granted to each identity and tool. Review servers before use, expose the minimum capability, separate reads from writes, treat returned content as untrusted, and preserve approval outside the agent for consequential actions.
Q8 · Shared infrastructure Max-score evidence: a reviewed allowlist, identity and per-tool authorization, short-lived credentials, audit logs, adversarial fixtures, and explicit write approval.
Threat-model the complete call
Section titled “Threat-model the complete call”user → client → model → MCP client → server → downstream system ↘ logs and artifacts ↗At every boundary ask: which identity acts, what data crosses, which operation is possible, where instructions can be injected, what is logged, and how the action is revoked or reversed.
- Allowlist reviewed servers. Pin package, command, endpoint, transport, owner, and approved versions. Re-review changes.
- Authorize per identity and tool. Filter exposed tools and data by the authenticated user; never rely on a shared all-powerful token.
- Start read-only. Prefer task-level reads. Put writes in separate tools with validation, preview, idempotency, confirmation, and external approval.
- Constrain execution. Use short-lived credentials, isolated runtime, network allowlists, input/output limits, timeouts, and rate limits.
- Test and observe. Run injection, malicious-returned-content, unauthorized, over-broad-query, replay, timeout, dependency-failure, and audit-correlation fixtures.
Prompts for an MCP security review
Section titled “Prompts for an MCP security review”Map every identity, credential, data class, tool, side effect, log, and downstream system in this MCP flow. Mark trust boundaries and the maximum blast radius of each credential.Review the tool catalog for excessive authority. Split reads from writes, replace generic shell/SQL/HTTP tools with narrow operations, and identify the approval required before each external side effect.Generate adversarial fixtures for prompt injection in tool descriptions and returned data, unauthorized identity, confused deputy, replay, schema abuse, timeout, and audit-log omission.Acceptance evidence
Section titled “Acceptance evidence”- Server source, package, endpoint, owner, and data route are recorded and reviewed.
- Credentials are scoped, short-lived where supported, revocable, and never exposed to the model.
- Write tools provide preview and idempotency and require policy-defined approval outside the model.
- Logs correlate principal, server, tool, decision, result, and approval while minimizing sensitive payloads.
- Client and server failure behavior is tested; missing security evidence fails explicitly.
Failure pattern: trust by protocol
Section titled “Failure pattern: trust by protocol”An approved MCP server can still expose an unsafe generic tool, return injected instructions, or call a downstream service with excessive privilege. Review and test the server’s actual version, configuration, identity, tool catalog, and downstream credentials—not the protocol label.
Continue with internal services
Section titled “Continue with internal services”Apply this model to Internal MCP servers and register their data routes in the AI data and compliance policy.