Since Anthropic introduced the Model Context Protocol in late 2024, MCP has become the default way to give AI agents hands: a standardized interface through which a model can call tools, read resources, and act on systems it could previously only describe. That standardization is genuinely useful, and it is also why MCP servers are now one of the most interesting targets in the stack. An MCP server sits at a trust boundary where untrusted, model-generated instructions meet real capabilities — file systems, databases, shell commands, cloud APIs. Get the boundary wrong and you have not built a tool integration; you have built a confused deputy that will faithfully execute whatever an attacker can talk the model into requesting.
The good news is that MCP security is not exotic. It is the same least-privilege, input-validation, and monitoring discipline you already apply elsewhere, applied to a new surface. Here are eight practices that matter most.
1. Treat the transport as a security decision
MCP servers commonly run over local STDIO (spawned as a child process) or over a network transport. STDIO servers derive their command and arguments from configuration, and if untrusted input can reach that configuration — a UI field, an API, or a prompt-injected instruction that rewrites the agent's own config — you can end up spawning attacker-chosen commands. Sanitize and allowlist the config-to-spawn boundary, validate flags rather than just program names (an allowlisted npx invoked with an execution flag is still arbitrary execution), and prefer authenticated network transports where the deployment allows it.
2. Scope every tool to the minimum it needs
Each tool an MCP server exposes should have the narrowest capability that still does its job. A "read customer record" tool should not also be able to write, delete, or query arbitrary tables. Define scopes explicitly, deny by default, and resist the temptation to ship one omnipotent run_query tool because it is convenient. The blast radius of a successful prompt injection is bounded by exactly what your tools permit.
3. Authenticate and authorize the caller
An MCP server should know who is on the other end and what they are allowed to do. Require authentication for network-exposed servers, bind tokens to specific scopes, and enforce authorization on every tool call rather than assuming the model or client already checked. The model is not a trusted principal; it is an intermediary relaying instructions whose origin you cannot verify.
4. Sanitize tool inputs as hostile
Every argument arriving at a tool is effectively user input laundered through a model. Validate types, enforce allowlists for paths and identifiers, reject shell metacharacters where you are not deliberately accepting a shell, and never pass model output directly into eval, a subprocess, or a raw query. The fact that a well-behaved model usually sends clean arguments is not a control.
5. Guard against tool poisoning and rug pulls
A malicious or compromised MCP server can hide instructions in tool descriptions that the model reads and obeys, or can behave benignly during review and turn hostile later. Pin the MCP servers you trust, review tool descriptions as you would review dependency code, and monitor for servers whose definitions change unexpectedly. Treat a third-party MCP server with the same suspicion you would give any third-party dependency with execution rights.
6. Log every tool invocation
You cannot investigate what you did not record. Log each tool call with its arguments, the identity that made it, and the result, and stream those logs somewhere durable. The signal that matters most is the sequence: a config change immediately followed by a new process spawn, or a benign-looking read followed by unexpected egress, is the shape of exploitation.
7. Constrain resource consumption
Agents loop. A tool that can be called without limit can be turned into a denial-of-wallet or denial-of-service vector by an agent stuck in a bad plan or driven there deliberately. Rate-limit tool calls, cap expensive operations, and set budgets so a runaway agent hits a wall instead of a bill.
8. Inventory what you actually run
Most teams cannot list every MCP server operating across their developers' machines and CI. Shadow MCP servers — installed for a one-off task and forgotten — are the ones nobody hardens. Maintain an inventory of MCP servers, their declared capabilities, and their transports, so an unsanitized surface is a tracked finding rather than an unknown.
How Safeguard helps
Safeguard approaches MCP from both sides of the boundary. As a platform, it exposes its own scanning and remediation capabilities through the Safeguard MCP server, so an AI agent can run a scan, retrieve findings, and even procure the platform through a governed, scoped interface — capabilities designed with least privilege and auditability built in rather than bolted on. As a security tool, Safeguard helps you govern the MCP servers you depend on: the Griffin AI detection engine inspects the code behind your integrations for the injection and command-execution patterns that turn a tool into a liability, and software composition analysis (SCA) tracks the packages your MCP servers pull in so a compromised dependency does not quietly extend an agent's reach. When a fixable weakness turns up, auto-fix remediation proposes the patch directly.
MCP is here to stay, and the teams that treat their MCP servers as privileged infrastructure — inventoried, scoped, authenticated, and logged — will get the productivity without the incident.
Want to give your AI agents a secure way to scan and remediate? Start free with Safeguard or explore the MCP integration documentation to connect your assistant today.