MCP server security: know what each server lets your agent do
An MCP server is a bundle of capabilities: every tool it exposes is something your agent can now do. Adding one, or upgrading one, is a change to your agent's authority, and it deserves the same review as a change to production access.
Why MCP servers are an authority problem, not just a dependency problem
The Model Context Protocol made it easy to give an agent new tools: add a few lines to .mcp.json and the agent can send email, query a database, or open pull requests. That ease is the point, and it is also the risk. The line that adds a server rarely says what the server can do, and a reviewer reading the diff sees a package name, not a capability.
A server is also code someone else maintains. When it updates, the tools it exposes can change, and so can what those tools do with the data that passes through them.
What has already gone wrong
In September 2025, version 1.0.16 of postmark-mcp, an unofficial npm package that wrapped the Postmark email API as an MCP server, was found to copy every email it sent to an outside address. Earlier versions behaved as advertised, so teams that pinned nothing picked up the change without a single line of their own code changing.
The lesson is not that MCP is unsafe. It is that an agent's reach is defined by configuration that changes over time, often without anyone deciding to change it.
What to review when an MCP server is added or changed
Treat each MCP change as a grant of authority and answer four questions before it merges:
- Which agent gains the server, and in which repositories?
- What can its tools do: read data, write data, send messages outside the organization, run code?
- Is it pinned to an exact version or digest, so an upstream release cannot change it silently?
- Has anyone in the organization approved this server, at this version?
How ControlLoop handles it
ControlLoop builds an Agent Capability Bill of Materials from your repository, including every MCP server each agent host is configured to use, and compares it with the last approved baseline. A pull request that adds or changes a server gets one plain-language sentence, for example: this change gives Claude Code the power to use the MCP server postmark, which sends email.
The CI gate then decides deterministically: pass, warn, require review, or block. On Team, servers are checked against your organization's approved-components list, with constraints such as a package, a version range, a digest, or a pin requirement, so an unapproved version is flagged even when its name is approved.