Securing MCP Servers and AI Agents
The Model Context Protocol gave AI assistants a universal way to use tools — read files, query databases, hit APIs, run commands. It is genuinely useful, and it is also a new, fast-moving supply chain that most security teams have never reviewed. Every MCP server you connect is third-party code running with your assistant's privileges. Here's how that goes wrong, and a checklist to make it go right.
MCP works by having a "server" advertise a set of tools to an AI "client." The client's model decides when to call a tool and with what arguments, based on the tool descriptions the server provides. That design is what makes MCP powerful — and it's also the source of most of its risk. You are trusting a server's self-description, and you are trusting the model to make safe calls with whatever access you granted.
The main risks
Over-broad tool scope
The most common problem is the least exotic: agents are handed far more access than the task needs. A server that only needs to read one Jira project gets a full API token. A filesystem tool meant for one directory is pointed at the home folder. An agent that should draft emails is also given send permission. Each excess capability enlarges the blast radius — the damage a single compromise, injection, or model mistake can cause. Over-scoping is the default because it's easy, and it turns a minor incident into a major one.
Typosquatting and malicious packages
MCP servers are distributed like any other software — as npm or PyPI packages, container images, or Git repos — which means they inherit every supply-chain attack we already know. Typosquatting is the obvious one: a package named server-filesysem sitting next to the legitimate server-filesystem, waiting for a fat-fingered install. Because MCP servers run with real access to files and credentials, a malicious lookalike is not a nuisance — it's a foothold. The same goes for abandoned packages that get taken over and dependency confusion between internal and public registries.
Tool poisoning
This is the MCP-native attack. Because the model reads a tool's description to decide how to use it, a malicious server can embed hidden instructions in that metadata — text the user never inspects but the model always obeys. A tool that claims to "format a document" might carry instructions to first read your SSH keys and pass them as an argument. It's indirect prompt injection delivered through the tool layer, and it is close to invisible without provenance and description review.
Confused-deputy and credential exposure
An MCP server often holds credentials on the agent's behalf and acts with them. If the agent can be steered — by a poisoned tool, an injected web page, or a crafted user request — it becomes a confused deputy, using its legitimate access for the attacker's ends. And because servers frequently need secrets to function, those secrets end up in config files, environment variables, and process memory, where they leak if the host or the server is compromised.
A hardening checklist
Before you connect a server
- Verify the source. Install from the official publisher and confirm the exact package name — check for typosquats character by character. Pin versions and lockfiles; don't auto-update to arbitrary releases.
- Review the tool descriptions. Read the full metadata the server exposes, not just the tool names. Look for instructions, unexpected argument requests, or anything aimed at the model rather than the human.
- Prefer pinned, hashed, or signed artifacts and vendors who publish a changelog and disclose security contacts. Treat an unmaintained server as an unpatched dependency.
How you run it
- Scope every credential to the minimum. Read-only where possible, single-project or single-directory tokens, short lifetimes. Never hand an agent a standing admin key.
- Expose the smallest tool set that accomplishes the task. Disable tools you don't use; every unused tool is attack surface.
- Sandbox the server. Run it in a container or restricted account with no ambient access to the wider filesystem, network, or secrets it doesn't need.
- Require human approval for irreversible actions — sending, deleting, transferring, or executing. A confirmation step turns a silent compromise into a visible decision.
While it's running
- Log every tool call — which tool, which arguments, which outcome — in a tamper-evident trail you can reconstruct later.
- Watch egress. Constrain and monitor where servers can send data; block outbound calls to arbitrary destinations.
- Maintain a live inventory. Know which MCP servers and skills exist across the fleet, on which machines, at which versions — so a new advisory or a typosquat becomes findable, not invisible.
- Rotate exposed secrets the moment a host or server is suspected, and be able to quarantine a compromised agent fleet-wide in one action.
None of this requires abandoning MCP — the productivity gains are real, and the protocol is improving. What it requires is treating agent tooling as the privileged, third-party, injectable software it actually is: vetted before it's connected, scoped to the minimum, isolated while it runs, and watched the whole time. The first prerequisite, as always, is visibility. You cannot harden the MCP servers and agents you don't know are running.