MCP Servers Run With Your Credentials. Someone Else Wrote Them.
MCP servers run with your credentials. Someone else wrote them.
Model Context Protocol has become the standard way to give AI assistants tools: file access, database queries, API calls, shell execution, calendar integrations, web search. The assistant gets a catalog of what it can do and calls these functions as it reasons through a task. The protocol is clean, the developer experience is good, and organizations are deploying it quickly.
What is happening more slowly is anyone applying security scrutiny to what they are actually installing.
What MCP Servers Actually Are
An MCP server is an external process that the AI client connects to over a defined protocol. It exposes a set of tools (functions the model can call with specific parameters) and a set of resources the model can read. When the AI is working through a task, it decides which tools to call, and the client executes them.
The tools run locally or as network services, authenticated to whatever resources they need access to. An MCP server that reads your calendar authenticates to your calendar service. One that queries your database needs database credentials. One that can execute shell commands runs on your machine with your permissions.
This architecture is intentional and useful. It is also a significantly expanded attack surface that most security teams have not had time to reason about carefully.
The Trust Problem
When you install an MCP server, you are making a trust decision about code that will run with your credentials and execute on behalf of your AI system. Most organizations are making this decision without the same scrutiny they would apply to a new browser extension or an npm package.
The Model Context Protocol specification itself is sound. The ecosystem of MCP servers being published to community registries is another matter. MCP servers can be written by anyone. They are distributed as packages or as links to run commands. They can do essentially anything the model decides to ask them to do, including things the original developer did not intend, if the server's tool descriptions are crafted to confuse the model about what the tool is for.
That last part deserves attention. An MCP server includes tool descriptions that the AI model reads to decide when and how to use the tool. Those descriptions are natural language. Adversarially crafted descriptions can steer the model toward unintended tool calls or away from noticing what a malicious tool is doing. The tool's interface is its attack surface for the model making decisions about it, before the tool is ever called.
The Registry Problem
NPM packages can contain malicious code. Developers learned this lesson expensively, and a supply chain security discipline grew up around it: lock files, integrity hashes, SCA scanning, publishing workflows that verify what is in the package before it ships.
The MCP server ecosystem is earlier than that. Community registries exist. Tools are published by individuals without organizational affiliation. Version pinning is inconsistent. There is no widely-deployed equivalent of SCA scanning for MCP server contents. An organization that has mature software supply chain security practices and no MCP governance is applying those practices to the part of the AI stack that matters less.
The attack scenarios are not hypothetical. A malicious MCP server can read credentials from the environment, extract context the model has accumulated in session, or execute commands the user would not have approved. It does this not by hacking the AI model but by being what the model was told it could call. The model follows its tool catalog. Someone else wrote the catalog entry.
Overprivileged Tool Registrations
Even well-intentioned MCP servers accumulate permission scope for convenience. A server built to assist with project management requests calendar access, email read access, and Slack posting ability because the original developer found those useful. Those permissions travel with the server when it is installed in a different organization's environment, by a developer who just wanted the project management functionality.
This is the browser extension problem, again, in a new context. The original developer needed those permissions for their use case. Every subsequent installation inherits them. The AI assistant now has tools that can read email and post to Slack in environments where nothing about the user's intended task requires it. When the assistant calls those tools in response to a prompt injection in a document it processes, the scope is already there.
Auditing installed MCP server permissions against the tasks those servers are actually needed for is not difficult. It is also not happening at most organizations with AI assistant deployments.
What Good Governance Looks Like
The starting point is an inventory. Before you can evaluate risk, you need to know which MCP servers are installed in your environment and what permissions they hold. This is the same question you would ask about installed browser extensions or third-party SaaS integrations. It is not being asked consistently for MCP.
From there, the evaluation framework is similar to any third-party component: who wrote this, is it maintained, does it come from a source with a verifiable identity and responsible disclosure process, and do the requested permissions match the stated functionality? An MCP server that requests shell execution for a tool described as a file formatter deserves scrutiny before installation, not after.
Internal development teams should publish MCP servers through an internal registry with code review rather than letting engineers pull ad hoc from community sources. Approved server lists work the same way in AI tool management as they do in browser extension policy: a short list of vetted options beats an open install-what-you-find default.
The model's decision layer needs hardening too. MCP implementations should be evaluated for prompt injection in tool descriptions, not just in user inputs. The tool description surface is where attacker influence on the model begins in the MCP attack chain, and it receives considerably less attention than the user input surface.
None of this requires waiting for the ecosystem to mature before deploying AI assistants with tool access. It requires treating MCP server provenance with the same seriousness applied to any other third-party code that runs in your environment with production credentials. That bar is not especially high. It is just not currently being applied.