MCP servers look harmless because they expose tools, not endpoints. A client calls a tool and gets a result. But the tools often touch a filesystem, a database, a package manager, or a deployment API. That makes the MCP server the authorization boundary, whether you planned it or not.
Here are the five failure modes I've seen show up in production and a short checklist you can run through before exposing a server to agents.
The client decides what a tool does by reading its declaration: name, description, and parameter schema. If the declaration lies, or drifts from what the handler actually does, the client's policy is enforcing the wrong thing.
Real examples: a tool declared as "read a file at this path" that silently tails a log stream; a "list packages" tool whose handler also accepts a --resolve flag that performs installs; a parameter added server-side that the client's declaration doesn't mention yet the agent keeps sending.
Mitigation: the client should pin the tool schema it authorized (hash it) and reject handlers whose live declaration diverges. Server-side, version the tool manifest and log every declaration change. Treat a declaration update the same way you treat a dependency bump — it's an authority surface.
A filesystem tool that accepts any path is a filesystem tool that accepts /etc/shadow, ~/.ssh, and every mounted secret. I've seen MCP servers ship a single read_file(path) and a single write_file(path, content) and then rely on the client to pass safe paths.
Clients are agents. Agents are given goals. If the goal is "fix this deploy" and the agent has a write_file that accepts any path, the shortest path to the goal sometimes writes to /etc or to a directory that the CI pipeline reads from.
Narrow the tools. Ship read_project_file(glob) scoped to the repo root, write_project_file(glob, content) scoped the same way, and a separate, explicitly-named tool for anything outside the project. Make the default "no" for the rest of the filesystem.
MCP servers run as processes. Processes inherit environment variables. It is common to run an MCP server inside a container or a CI step that also carries DATABASE_URL, AWS_ACCESS_KEY_ID, or a signing key.
An agent with a "run command" tool or a filesystem tool can read /proc/self/environ or list the directory a shell writes .env files to. The server didn't ship a "read secrets" tool, but the tools it did ship composed into one.
Drop sensitive variables at the server boundary, not at the agent boundary. Run the MCP server with a minimal environment and pass only what its tools need. If a tool needs a credential, pass it through the server's own secret store, not through the process environment the agent can observe.
A tool that fetches a URL, installs a package, or calls a registry can turn an MCP server into a data exfiltration or supply-chain hop. The client authorized the tool; the tool's network destination is what determines the blast radius.
Treat outbound connections from the MCP server like outbound connections from any service that runs untrusted input: an allowlist of destinations, and nothing else. Package installs go to the pinned registry. API calls go to the declared host. Everything else is dropped.
You don't need a full egress proxy to get started. Even iptables rules or a container runtime's network policy on the MCP server process surface is enough to make the difference between "the agent fetched a template" and "the agent phoned home with a config file."
You cannot defend what you cannot replay. Every tool invocation the server executes should be logged with: the calling client identity, the tool name, the input parameters (redacted for credentials), the outcome, and a server-side timestamp.
Logs should be append-only after the fact and shipped out of the host the server runs on. If an agent has a filesystem tool on that host, it has a write tool on the log file.
Run this against every MCP server you expose to an agent before you let it run workloads:
MCP servers aren't untrusted in the browser sense. They're more like a CI runner that an agent can steer. Secure them like one.
I'm building Cirvix AgentControl, an open-source default-deny policy layer for agent tool calls: https://github.com/CIRVIX/agent-control (try npx @cirvix_ai/agent-control scan).