MCP (Model Context Protocol) server security is not finished when you vet the server. Tool poisoning, over-scoped tokens and supply-chain flaws remain real. The control that still holds is outside the server: even a poisoned or compromised MCP server cannot exceed the API scope enforced downstream.
Most guidance tells you to pick trusted publishers, sign packages, sandbox the process and log tool calls. Do that. Then assume the server you approved can still lie about what it will call.
The approved server that asked for payroll
A security architect at a state agency had done the intake. The MCP server was on the approved registry, signed, and limited (on paper) to a CRM read tool. A week later an analyst asked why the model had summarised an employee’s bank details. The server’s tool description had been updated in place – a classic tool-poisoning pattern. The client still trusted the same server name. The CRM token the server held could read payroll objects. Nothing downstream refused the extra call.
Maryland’s Department of Information Technology (DoIT) now treats that class of failure as a named risk. Its May 2026 MCP guidance, revised 8 September 2026, lists tool poisoning, identity-boundary collapse, static keys and missing audit as reasons “Shadow MCP servers–those installed without DoIT knowledge–are prohibited.” Approval is necessary. It is not sufficient if the only enforcement lives inside the server that just changed its own description.
Is MCP safe?
MCP is a connection standard. It is as safe as the identity, scope and audit you put around it.
The Cloud Security Alliance republished Darktrace’s 15 June 2026 briefing, “7 MCP Risks CISOs Should Consider and How to Prepare.” The piece is explicit: MCP “handles only the mechanics of the connection” and does not include identity or access controls. Treat MCP as critical infrastructure, then add those controls yourself.
JFrog disclosed CVE-2025-6514 in mcp-remote versions 0.0.5 to 0.1.15: a CVSS 9.6 issue that lets an untrusted MCP server drive OS command execution on the client when it connects. The fix is 0.1.16 and a policy of not connecting to untrusted servers over cleartext. That is a client-side supply-chain flaw. It is also a reminder that “we only use official packages” is a moving target.
Maryland DoIT’s guidance cites a study of 5,200 open-source MCP servers: 53% relied on static API keys and only 8.5% used OAuth. It also notes an analysis of more than 2,500 MCP plugins that granted file-system, shell and network access together. Those figures describe the public ecosystem, not your private registry. They explain why a CISO cannot treat “we installed MCP” as a completed control.
What are the main MCP security risks?
The recurring classes are poisoned tools, rogue or untrusted servers, over-scoped credentials, supply-chain compromise, and missing attribution.
CSA’s seven items (content injection, tool abuse, cross-agent contamination, supply chain, unintentional behaviour, confused deputy, governance blind spots) overlap Maryland’s table (identity-boundary collapse, prompt injection, tool poisoning, excessive permissions, credential compromise, supply chain, local and browser-agent risk, confused deputy, weak logging). The useful split is not another taxonomy. It is where the control sits.
| Risk | Control inside the MCP server | Control outside the server |
|---|---|---|
| Tool poisoning (description or behaviour changes) | Signed releases, integrity checks, human review of tool lists | Downstream rules that allow only named methods and paths, so a new “payroll” tool still cannot call payroll |
| Rogue or untrusted server | Registry, publisher vetting, TLS to known hosts | The vendor API credential is not in the server. The server presents a proxy credential that only reaches approved targets |
| Over-scoped token | Server claims to request least privilege | Token never issued to the server. Per-call scope on the proxy is narrower than the vendor grant |
Supply-chain CVE in the server or client (mcp-remote 2025-6514) | Patch, pin versions, sandbox | Blast radius is the grant on the proxy, not the vendor key or the whole SaaS tenant |
| Prompt injection that makes the agent call a tool | Input filters, confirmation prompts | The tool call still has to pass request-shape rules. Writes and extra objects are denied |
| Confused deputy | Server implements user-to-tool auth | Each caller has its own proxy credential. The server cannot spend another assistant’s grant |
| Missing audit | Server logs tool names | The API hop records which caller, which target, allow or deny, even if the server’s log is gone or forged |
Inside-the-server controls are still required. Maryland’s tiers (local stdio, remote read-only, write-capable with OAuth) and CSA’s “Treat MCP as critical infrastructure” are the right starting policy. They fail open the moment the server is the thing that was poisoned.
Why control outside the server still holds
Because the MCP server is a client of the APIs you care about. You can govern that client the same way you govern any other unofficial integration.
An MCP server that calls Salesforce, Xero or a payments API is making outbound HTTP. If those calls pass through a proxy that already decides method, path and response, the server can be wrong, greedy or compromised and still not get payroll. That is the stance: control outside the server.
This is the same egress seam as outbound API governance. The MCP server is one more caller. It should not hold the vendor key. It should not see fields the task does not need – response-side redaction removes them before they reach the model, which is also where the lethal trifecta loses a private-data leg.
Confirmation prompts in the client are useful and bypassable. A deterministic deny on POST /payroll is not a suggestion to the model.
What should CISOs require before an MCP server reaches production?
Approval, least privilege at the vendor, and a second enforcement point the server does not own.
- Intake. No shadow servers. Maryland’s rule is the right default: only a named registry, with a re-vet when a tool gains write or outbound access.
- Authentication tier. Local stdio is not the same as a remote write-capable server. Maryland requires OAuth on write-capable or high-sensitivity tiers and disqualifies shared static keys there.
- Vendor credential isolation. The MCP server does not store the SaaS token. A proxy does.
- Request-shape rules. Default deny. Allow only the objects and methods in the approved use case.
- Response filters. The model receives the fields the task needs, not the vendor’s full record.
- Audit on the hop. Tool-name logs in the server are extra. The API record is the one you keep when the server is the suspect.
- Patch policy. CVE-2025-6514 is the template: pin client versions, refuse untrusted servers, treat “official package last month” as stale.
Red-team the approved server as if it will later grow a new tool. If that tool can still reach only the original grant, the outside control is doing the job.
Where RequestRocket fits
RequestRocket sits on the outbound calls the MCP server makes to APIs you do not host. It holds the real API credential. The server uses a proxy credential. Rules and filters apply per call. Telemetry records allow and deny. You can expose the same proxy as an MCP server so the assistant never talks to an untrusted third-party MCP that holds your keys.
It does not replace Maryland-style intake, code signing or client patching. It does not provide a model and does not “detect” poisoning with AI. It is the downstream grant those processes cannot enforce once the server has changed.
FAQ
Is MCP safe to use in production?
It can be, if you treat it as a high-risk integration: approved servers only, least privilege, and enforcement that does not live only inside the server. MCP itself does not provide that enforcement.
Does vetting MCP servers replace runtime controls?
No. Vetting answers who published the code you started with. Runtime scope answers what tonight’s process is allowed to call after the tool list changes.
Should we block all third-party MCP servers?
Many public-sector and bank policies will. If you allow any, put the vendor credential and the request-shape rules outside that server. A block-list of publishers is not a substitute for per-call deny.
What did CVE-2025-6514 actually do?
JFrog reported OS command injection in mcp-remote 0.0.5–0.1.15 when the client connected to an untrusted MCP server. The fix is 0.1.16 and a trusted-server policy. It is a client compromise, not an excuse to leave vendor keys in the server.
Do we still need OAuth on the MCP server?
Yes, for the server-to-client and server-to-user relationship Maryland describes. OAuth on the server does not scope the SaaS API calls the server then makes. That is a separate credential on a separate hop.
How does this relate to prompt injection?
Injection can make the agent want a tool. Outside-the-server rules decide whether that tool call is allowed to reach the API, and what comes back. You need both.
Book a walkthrough of RequestRocket
Sources
- Maryland DoIT, MCP Guidance for Responsible and Safe Usage v2.0 (issued 15 May 2026, revised 8 September 2026)
- Cloud Security Alliance, 7 MCP Risks CISOs Should Consider and How to Prepare (15 June 2026; originally published by Darktrace)
- JFrog, CVE-2025-6514 Threatens LLM clients
- NVD, CVE-2025-6514
- CSAI Foundation, Securing the Agentic Control Plane