# MCP Security Checklist for Coding Agents

A practical checklist for engineers and leads approving MCP servers and tool calls before Claude Code, Cursor, OpenCode, Codex, GitHub Copilot Coding Agent, or similar tools change a real repository.

## Core rule

MCP tools are not just context. They are authority. Review which tools the agent can call before execution, and route any meaningful permission expansion back to the human reviewer.

## 1. Inventory the MCP servers in the workflow

- [ ] List every MCP server the coding agent can reach for this task.
- [ ] Record whether each server is local, internal, hosted by a vendor, or community/open-source.
- [ ] Name the human owner who can explain why that server is needed for this run.

## 2. Classify tool effects, not just tool names

- [ ] Mark each tool as read, write, execute, credentialed, external-send, or deploy/release-affecting.
- [ ] Treat tools that send messages, create tickets, mutate data, run shell commands, or call production APIs as high-effect tools.
- [ ] Do not approve an entire MCP server just because one read-only tool is useful.

## 3. Approve MCP access per task

- [ ] Tie each approved MCP tool to the current outcome and blast radius.
- [ ] Require review if the agent asks for a new server, a broader permission, or a write/external-send action that was not in the original plan.
- [ ] Prefer temporary, task-scoped permissions over standing broad access.

## 4. Separate untrusted context from authority

- [ ] Assume files, issues, webpages, and chat messages can contain instructions the model may follow unless bounded.
- [ ] Do not let retrieved content expand tool authority or override the approved plan.
- [ ] Stop if the agent cites external/untrusted text as justification for broader permissions.

## 5. Define logging and handoff evidence

- [ ] Keep a record of which MCP tools were approved, invoked, denied, or escalated.
- [ ] Require the final handoff to include tool-call evidence relevant to the approved outcome.
- [ ] Preserve drift decisions: what changed, who approved it, and what validation evidence supports it.

## Put MCP approval inside the Goal Contract

For Caskade, MCP approval is part of the pre-execution boundary: what outcome is allowed, which tools are in scope, what validation proves the run stayed inside that boundary, and when the agent must stop.

Bring a real workflow: https://caskade.dev/?utm_source=resource&utm_medium=markdown&utm_campaign=mcp-security#access