MCP changes the shape of agent risk. Without tools, an agent mostly produces text. With tools, an agent can read files, query systems, open browser sessions, call APIs, search internal data, create tickets, update repositories, or trigger workflows.
That is the point of MCP. It gives agents useful hands. It also means the security question is no longer only: "Is the model allowed to answer this prompt?" The better question is: what can this agent reach through the MCP servers connected to it?
An MCP server is not just a plugin label in a settings page. It is a running software dependency. It has its own package tree, transport layer, credentials, tool definitions, input validation, network behavior, and update cycle.
If that server is vulnerable, misconfigured, or simply too permissive, the impact can move beyond bad text. It can become action.
The agent may reach systems the user did not think were exposed
Many MCP servers sit next to useful systems: source control, databases, ticketing systems, cloud APIs, search indexes, browsers, payment systems, file systems, and internal HTTP services.
The user may think they are asking an assistant a narrow question. The agent may actually have a tool path into a much larger environment.
The practical failure mode looks like this:
- A server exposes a broad tool.
- The tool accepts user-controlled input.
- The server runs with a credential that has more access than the task needs.
- The agent makes a call that crosses the intended boundary.
Even if nobody intended abuse, the blast radius is now defined by the server's credential and reachable backend, not by the original chat prompt.
A vulnerable dependency can become part of the agent runtime
Security scanners often look at the package named in a config file. That is useful, but incomplete.
The code that actually runs is the installed tree: the server package plus everything it pulls in.
If an MCP server depends on a vulnerable SDK, HTTP client, parser, browser automation layer, or framework, the relevant question is whether that dependency is on a path the agent can reach.
Sometimes the answer is no. The vulnerable package exists but is not used in the active server path. Sometimes the answer is yes. The dependency handles tool requests, tool responses, local HTTP transport, remote API calls, or file uploads.
That difference matters. Dependency presence is a signal. Reachability is the next question.
Tool descriptions and tool outputs become part of the trust boundary
MCP tools are described in text. Agents read that text to decide when and how to call tools.
That means tool names, descriptions, schemas, error messages, and returned content are not passive metadata. They influence agent behavior.
A weak tool boundary can show up as:
- Overly broad descriptions that invite unsafe use.
- Tool output that mixes trusted data with untrusted instructions.
- Error messages that reveal internal paths or operational details.
- Returned content that the agent treats as guidance instead of data.
Agent systems need a clear instinct: separate instructions from data, and treat tool output as untrusted unless policy says otherwise.
Localhost does not automatically mean private
Many MCP servers run locally. That can feel safe because the service is not intentionally exposed to the internet.
Local is better than public, but it is not a complete security boundary. Local services still need careful transport choices, host validation, origin assumptions, and authentication behavior.
The risk is not that every local server is exposed. The risk is assuming "localhost" ends the conversation.
Credential-bearing tools raise the stakes
The most important MCP servers are often the ones holding credentials.
An API key, OAuth token, service account, browser session, or database credential changes the severity of otherwise ordinary bugs. A parsing flaw, request-routing issue, SSRF-like behavior, unsafe redirect, or overly broad tool can become more serious when the server uses a privileged credential to make the request.
The right credential for an MCP server is not "whatever works." It should be scoped to the task, limited by environment, revocable, logged, and separate from human admin credentials.
Logs may not be enough after something goes wrong
If an agent makes a tool call that changes production data, reads sensitive content, or triggers a workflow, a generic log line is often not enough.
A useful receipt should answer:
- Which identity initiated the action?
- Which agent made the tool call?
- Which MCP server and version handled it?
- Which tool was called?
- Which policy allowed or denied it?
- Which credential class was used?
- What was the result?
- Was the server dependency tree known at the time?
What teams should do before connecting MCP to production
- Inventory every MCP server.
- Record package versions and lockfiles.
- Scan the installed dependency tree, not only the direct package.
- Review the tools exposed by each server.
- Map each tool to the systems and credentials it can reach.
- Use scoped credentials.
- Disable unused tools.
- Prefer local-only binding unless remote access is required.
- Add policy around risky tool calls.
- Keep receipts for agent actions.
MCP is useful because it gives agents operational reach. Operational reach needs operational controls.