MCP server security: reviewing servers before you connect
Connecting an MCP server is closer to installing a plugin with broad trust than to adding a dependency. The server’s tools become the agent’s hands: file access, shell commands, HTTP calls, database queries. If the server is malicious or merely sloppy, the damage happens at agent speed — and the agent will happily act on instructions that came from an untrusted document. The question is not whether to use MCP servers, but what to check before you connect one.
What you are actually trusting
When an agent calls an MCP tool, it passes arguments derived from the conversation. That means the server sees content from every source the conversation touched, including untrusted files and web pages. A server can also send tool results back into the conversation, which is how a compromised server feeds the agent instructions. Trusting a server means trusting its tools, its authors, and its runtime all at once.
Where the server runs matters
- Local stdio servers. The server runs on your machine and communicates over stdin and stdout. Its power is your power — if it can read your files, the agent can too.
- Remote HTTP servers. The server runs elsewhere and the agent sends requests over the network. Now you are trusting the operator, the transport, and whatever the remote host does with the conversation data it receives.
Both are legitimate. Neither should be connected without review.
A review checklist before you connect
Read the source or the provenance. If the server is a package, check the registry metadata, the maintainer, and the release history. If it is a single script, read the whole thing. Pin the version you install; unpinned servers change behavior silently.
List the exposed tools. Write down every tool the server advertises and what it can do. A server that exposes a shell tool and a server that exposes a documentation search have very different trust requirements.
Check where credentials go. Does the server need your API keys? Where does it read them from? If the answer is “the agent’s environment”, then every key the agent holds is visible to the server.
Trace the network egress. Can the server reach anything, or is it restricted? A server with outbound access can exfiltrate whatever it reads.
Ask what it logs. Server logs can hold tool arguments, which can hold secrets. Know where logs go and what they retain.
Check the permission model. Does the server enforce its own authorization, or does every caller get full access to every tool?
Operational patterns that reduce risk
Run local servers with the least privilege they need: a dedicated account, no broader filesystem access than required, and no ambient credentials. Keep remote servers behind TLS with authentication. Watch tool calls in your audit trail, and treat any server that stops being maintained as a candidate for removal.
Credential isolation
The strongest pattern is to keep credentials out of the server’s reach entirely. If the agent and the server never hold the key, a compromise of either exposes nothing. Credentials can be injected at the edge instead — a broker that stands between the tool call and the upstream API, adding headers or performing OAuth at request time. That is the pattern used by trustless, whose proxy injects credentials for HTTP tools and whose audit log records every injection and denial without ever containing token values. Details are in the documentation.
How many MCP servers do you have connected right now, and for how many of them have you actually read the source?