The Minimum Security Checklist for MCP Servers
MCP servers are becoming the default way to connect AI agents to real systems. That is good for developer velocity. It also means every MCP server is now part of the agent security boundary.
Before you expose an MCP server to real users, check the basics.
Separate read tools from write tools
Read tools and write tools should not feel the same to the agent or the operator.
Reading a calendar event is one risk level. Updating it is another. Listing tickets is one risk level. Closing a ticket is another.
Name tools clearly and document their side effects. If a tool mutates state, the name should make that obvious.
Validate arguments at the tool boundary
Do not trust the model to call your tool correctly. Treat tool arguments like public API input.
Use schemas. Reject unexpected fields. Enforce enums. Cap string lengths. Validate IDs against the authenticated user's scope. If a tool accepts natural language, separate the language field from the action fields the server actually executes.
The model can be tricked. The tool boundary should not be.
Scope credentials per user and per workspace
Shared service credentials are convenient and dangerous. If one agent call can access every customer's data through the same MCP credential, a single injection becomes a broad incident.
Use per-user or per-workspace credentials wherever possible. At minimum, enforce a server-side scope check on every tool call.
Require confirmation for destructive operations
Deleting, sending, publishing, changing permissions, and modifying billing should not happen silently.
If your MCP client supports confirmation gates, use them. If it does not, design the tool as a two-step workflow: prepare the change, return a summary, then require a separate commit action.
Log every write
Logs are not just for debugging. They are how you reconstruct an agent incident.
For every write call, log:
- User or workspace
- Tool name
- Validated arguments
- Source task or conversation ID
- Timestamp
- Whether human confirmation happened
- Result or error
Do not log secrets or full private documents. Do log enough to understand why the action happened.
Test with hostile tool outputs
MCP servers do not only receive model calls. They return text back into the agent context. That output can become an injection carrier if it includes user-controlled content.
Test what happens when a tool returns a record containing instructions like "ignore all previous instructions." The agent should treat that as data, not authority.
The bottom line
MCP makes agents useful because it gives them tools. That also makes MCP one of the most important places to enforce security.
BreakMyAgent tests agents against prompt injection patterns that target tool calls and returned context. If your MCP server can write to anything important, test it before shipping.