Quick answer
Treat every MCP server as a tool boundary. Start read-only, restrict credentials, log tool calls, isolate network access, and require review before connecting agents to production systems.
Threat model
Prompt injection can steer an agent toward unsafe tool use if external content is trusted too much.
Over-broad MCP tools can expose secrets, private files, customer data, or production write paths.
Unreviewed third-party servers can create supply-chain risk inside developer workflows.
Minimum controls
Use least privilege, environment-gated credentials, explicit user approval for destructive operations, network isolation where possible, and logs that connect tool calls to sessions and users.
Recommended play
- Inventory MCP servers by data class and action type before connecting them to coding agents.
- Separate read tools from write tools, then require explicit approval for destructive or production-facing actions.
- Treat logs as product requirements: every meaningful tool call should be attributable to a user, session, server, and purpose.
MCP security control checklist
Use this control view to decide whether a server can be used in a personal repo, team repo, or production workflow.
| Area | Minimum control | Why it matters | Launch gate |
|---|---|---|---|
| Least privilege | Baseline permission model | Limits blast radius if an agent follows bad context | Scopes match the actual workflow |
| Secret handling | Credential and logging policy | Prevents credentials from entering prompts or logs | Secrets stay in environment or vault-managed paths |
| Write separation | Read/write boundary | Keeps read workflows fast while protecting destructive operations | Write tools are isolated and approval-gated |
| Audit logs | Traceability requirement | Makes incidents debuggable and policy review possible | Logs include actor, session, tool, target, and outcome |
Execution steps
Create the server inventory
List each MCP server, owner, data exposed, tool methods, credential source, and whether it can write or delete.
Classify data and actions
Mark public, internal, confidential, customer, production, and secret-bearing paths so permissions match risk.
Gate write capabilities
Split read and write tools where possible, then require human confirmation for destructive or production-facing actions.
Review third-party servers
Check source, vendor posture, update path, and transitive dependencies before adding a server to team defaults.
Common pitfalls
Treating all MCP tools as equal
Score each tool by data sensitivity, write ability, and network reach before enabling it broadly.
Logging too little
Record enough context to reconstruct what happened without storing secrets or private payloads unnecessarily.
Skipping prompt-injection assumptions
Assume external content can be hostile and keep dangerous tools approval-gated.
Implementation checklist
- Inventory every MCP server and owner.
- Mark data classes exposed by each tool.
- Keep secrets out of prompts and logs.
- Separate read tools from write tools.
- Require human approval for destructive actions.
- Review third-party server source or vendor posture.
Questions this guide answers
What is the answer to secure MCP servers for AI coding agents?
A security checklist for using MCP servers with coding agents, focused on permissions, secrets, tool scopes, and auditability.
Who is this security checklist and threat model for?
Engineering leaders, security reviewers, platform teams, and developer tooling owners.
Which sources support this guide?
This guide is grounded in official or high-confidence sources from MCP, GitHub, Anthropic.