What is MCP security?
MCP security is the practice of protecting the Model Context Protocol (MCP), the open standard that lets AI applications connect to outside tools, files, databases, and services. Each connection runs through an MCP server, which acts as a go-between: it receives a request from an AI agent and turns it into a real action, like reading a file, querying a database, or sending a message.
MCP security covers everything around that go-between: the servers themselves, the tools they expose, the credentials they hold, and the data and actions an AI agent can reach through them.
It matters because an MCP server often holds broad access on the agent’s behalf. If the server is untrustworthy or poorly configured, anything it can reach is exposed.
How safe are MCP servers?
MCP isn’t inherently unsafe, but its safety depends on the server, the permissions it holds, and how it’s deployed. Two things raise the stakes. Anyone can publish an MCP server, and installing one usually gives it standing access to whatever credentials it’s configured with. And the AI model reads the server’s tool descriptions and follows them, which opens attack paths that traditional software doesn’t have.
These are the main risks:
- Tool poisoning: An attacker hides malicious instructions inside a tool’s description. The model reads and follows them, but the user rarely sees them in a normal review. The instructions might tell the model to send data somewhere it shouldn’t go.
- Rug pulls: A server behaves correctly when you approve it, then changes its tool definitions in a later update. The approval you gave no longer matches what the server does.
- Prompt injection through tool output: A tool retrieves a web page, document, or email that contains hidden instructions, and the model treats them as commands.
- Confused deputy attacks: The server uses its own broad authority to act for a user who was never allowed to do that. Passing a user’s token straight through to another service, known as token passthrough, is a common way this goes wrong.
- Over-permissioned credentials: Servers are often connected with far broader access than their tools need. One compromised tool can then reach much more than it should.
- Supply chain risk: Malicious or lookalike servers can impersonate popular integrations, and a trusted server’s dependencies can be tampered with. This is the same problem as malicious packages, applied to AI tooling.
- Implementation flaws: Servers written quickly can contain classic bugs, such as command injection, server-side request forgery, and path traversal.
- Exposed and shadow servers: Servers left reachable on a network without authentication, or set up by employees without IT knowing, are easy targets and easy to overlook.
The reasoning here is layered. A poisoned tool description is only dangerous if the agent has access worth stealing, and that access is only exposed if nobody is watching the server. That’s why the fix is rarely one control. It’s limiting what each server can reach, verifying what you install, and keeping visibility over what’s running.
Do MCP servers require authentication?
Not by default. The MCP specification makes authorization optional, so a server can run with no login at all. That’s fine for a tool running on your own laptop, but risky for anything reachable over a network.
How authentication works depends on how the server connects:
- Local servers (stdio): These run on the same machine as the AI application, launched by it. They usually skip a login flow and read credentials from the environment, such as environment variables. The main risk is that whatever runs the server inherits those credentials.
- Remote servers (HTTP): These are reachable over a network, and the specification recommends OAuth 2.1 for them. The MCP server acts as a resource server that validates access tokens issued by a separate authorization server. Tokens should be short-lived, limited to specific scopes, and issued for that particular server rather than reusable elsewhere.
There are actually two authentication questions to answer:
1. Who is calling the server? The client, and the user or agent behind it, must prove its identity before the server acts.
2. What is the server allowed to do downstream? The server holds its own credentials for the services it connects to, and those need the same care.
These mistakes come up repeatedly:
- Running a network-reachable server with no authentication at all
- Sharing one long-lived API key across many agents or users, so nobody can tell who did what
- Accepting tokens that weren’t issued for the server and passing them along to other services
- Granting broad scopes “just to make it work”
Authentication is only the first gate. Verifying an agent’s identity proves who it is, not what it should be allowed to do. That’s why access is not authorization: each agent should have its own identity and a narrowly scoped set of permissions. Treating agents and servers as non-human identities, each with an owner and a defined lifecycle, makes this manageable at scale.
What are the best practices for MCP servers?
Good MCP security comes down to verifying what you run, limiting what it can reach, and watching what it does.
Before you install a server:
- Prefer official or verified publishers, and check the source before connecting anything.
- Pin server versions and turn off automatic updates so a rug pull can’t slip in.
- Read the tool descriptions, not just the tool names.
- Keep an inventory of every MCP server in use, including ones employees added on their own.
When you grant access:
- Apply least privilege. A server that reads tickets shouldn’t hold write access to your repositories.
- Use a separate credential for each server, so one compromise doesn’t spread.
- Keep tokens short-lived and scoped, and store secrets in a secrets manager rather than in configuration files.
- Require human approval for high-impact actions like deleting data, sending external messages, or moving money.
If you host your own MCP server:
- Run it locally over stdio when only one user needs it, to avoid network exposure altogether.
- For remote servers, require TLS and OAuth, and never leave one open to the whole network without authentication.
- Bind the server only to the interfaces it needs, and run it in a container with minimal permissions.
- Validate every input the server accepts to block command injection and path traversal.
- Add rate limits, and segment the server from systems it doesn’t need to reach.
Once it’s running:
- Log every tool call, and alert when a tool’s definition changes from what you approved.
- Watch for unusual sequences, such as a tool reading a secret and another sending data out right after. Test regularly for exposed or forgotten servers.
Taken together, this is a zero trust approach: no server, tool, or agent is trusted just because it’s connected. Each one has to prove its identity and stay within its scope, every time.
