Are MCP Servers Secure? Risks, Attacks, and Controls

The question is usually asked about the protocol, but the protocol is not where the risk is. MCP describes how a tool is advertised and called. Everything that makes a deployment safe or unsafe sits around it.

What does the MCP specification actually cover?

Tool description, discovery, invocation, and transport. It does not define authentication between a client and a server, an authorization model, or an audit requirement. Recent revisions added security guidance, but guidance is not enforcement.

This is a reasonable design for a protocol. It becomes a problem when teams read "standard" as "safe" and connect a server holding production credentials.

What is the biggest practical risk?

Prompt injection, because it turns a data-access problem into an action problem.

A model reads content from somewhere: an issue, an email, a web page, a document. If that content contains instructions, the model may follow them, since it has no reliable way to separate data it was asked to process from instructions it was asked to obey. With no tools attached, the worst case is a bad answer. With tools attached, the model can act on the injected instruction using real credentials.

The mitigation is layered: inspect tool calls before they execute, keep the credential scope narrow enough that a successful injection has a small blast radius, and require approval for destructive actions.

What goes wrong with credentials?

The common failure is mundane. Someone pastes an API key into a config file to get a server working, it works, and a teammate copies it. Months later nobody knows who created the key, what it can reach, or when it expires.

Two properties fix this. Credentials should be per user, so a call is limited to what that person could already do. And they should never be handled by the person, so there is nothing to paste or copy.

This is also what makes an incident answerable. If an agent deletes the wrong record, the first question is whose access it used. A shared key on a laptop has no answer.

How risky are third-party MCP servers?

A community server is a dependency that will hold credentials to one of your systems. That deserves the scrutiny you would give any such dependency: who maintains it, whether you can read the source, and what scopes it asks for.

Supply chain risk here is real rather than theoretical. We wrote up one incident in What the Composio security incident says about MCP security.

The practical answer is isolation. Run third-party servers in their own environment with their own network boundary and narrow scopes, so a compromised one cannot reach beyond the system it serves.

What does a secure deployment look like?

• Employees authenticate through your existing identity provider; nobody handles an API key by hand.
• Tool access is bound to roles and groups, granted on the first day and removed on the last.
• Every call is inspected for injection before it executes.
• Every session is recorded with arguments, results, and the acting identity.
• Third-party servers run isolated, with their own networking and firewall rules.
• The deployment model matches your data rules, up to on-prem if required.

How does Metorial address this?

Metorial supplies those controls as the default rather than as configuration. Employees sign in through SSO and never touch a key. Access control binds tools to roles. Protoguard checks calls for prompt injection before execution. Tracing records every session with the identity behind it. Servers run in isolated enclaves with their own networking, and the platform is SOC 2 Type II and GDPR compliant with on-prem available.

Where it is weaker: if you need certification beyond SOC 2 Type II, some competitors have gone further with third-party conformance specifications, and we say so in Best Enterprise MCP Gateways. Protoguard also reduces prompt injection risk rather than eliminating it, which no product can honestly claim to do.