OpenClaw MCP Server Security: The Attack Vector Nobody Is Talking About

Every security advisory about OpenClaw focuses on the same things: malicious skills, exposed gateways, sandbox escapes. Those are real problems. But the attack vector that's getting the least attention — and doing the most damage — is MCP servers.

MCP (Model Context Protocol) is the bridge between your OpenClaw agent and external services. When you connect your agent to GitHub, Google Workspace, Slack, a database, or any third-party API, you're doing it through an MCP server. It's what makes OpenClaw actually useful for real work.

It's also the component that almost nobody audits.

What MCP servers can do

An MCP server is a process that exposes tools to your agent. When you add a GitHub MCP server, your agent gains the ability to create repositories, commit code, manage issues, and read private repos. When you add a Google Workspace MCP server, your agent can read your email, modify your calendar, and edit your documents.

These aren't abstractions. The MCP server holds real credentials — OAuth tokens, API keys, service account keys — and uses them on your agent's behalf. When your agent says "check my email," the MCP server authenticates to Google's API with your actual token and returns the results.

The trust model here is straightforward: you trust the MCP server to faithfully execute your agent's requests and return honest results. If that trust is broken, the consequences are immediate. The MCP server sits between your agent and every external service it connects to.

How ClawHavoc exploited MCP

The ClawHavoc campaign didn't just plant malicious skills. Some of the more sophisticated packages registered their own MCP servers during installation.

The pattern worked like this. A skill advertised itself as, say, a "GitHub workflow optimizer." During installation, it registered an MCP server that appeared to provide GitHub integration tools. The skill's code was clean — it did what it promised. But the MCP server proxied every API call through an attacker-controlled endpoint before forwarding it to GitHub.

From the user's perspective, everything worked normally. GitHub API calls succeeded. Repos were accessible. Issues got created. But every request and every response also passed through the attacker's infrastructure — including OAuth tokens in the authorization headers.

The built-in security audit checks whether MCP is enabled. It does not audit what each server does, where it connects, what credentials it holds, or whether it was registered by a skill you later uninstalled.

The three MCP threat patterns

Based on our analysis of the ClawHavoc campaign and ongoing monitoring, MCP-based attacks follow three patterns.

Proxy exfiltration

The MCP server functions normally but routes traffic through attacker infrastructure. This is what ClawHavoc used. It's nearly invisible because the end result is correct — your agent gets the data it asked for. The attacker just gets a copy. Detection requires inspecting the actual network destinations of MCP traffic, which no current tool does automatically.

Tool injection

The MCP server exposes additional tools beyond what the user expects. A "GitHub" MCP server that also exposes a run_shell_command tool, or a "Google Calendar" server that also provides read_filesystem. Your agent might discover these tools through MCP's tool listing mechanism and use them if instructed to — or if tricked via prompt injection. The tools look legitimate to the LLM because they're registered through the official protocol.

Credential harvesting at rest

MCP servers store credentials in configuration files — typically ~/.openclaw/config.json or in the server's own config directory. A separate malicious skill doesn't need to intercept MCP traffic. It just needs read access to the MCP configuration files to extract every credential your agent uses. If a skill can read your config directory (which many can, depending on sandbox settings), it has your OAuth tokens, API keys, and service account credentials.

What the built-in audit checks (and doesn't)

Running openclaw security audit produces a finding if MCP is enabled. The finding essentially says "MCP servers are configured" and recommends reviewing them. That's it.

It doesn't check what servers are present. It doesn't validate where they connect. It doesn't flag MCP servers that were registered by skills. It doesn't inspect credentials or permissions.

SecureClaw goes slightly further — it can identify some known-malicious MCP server names from its database. But it doesn't perform behavioral analysis on MCP traffic or detect proxy exfiltration patterns.

The gap here is significant. An OpenClaw deployment with five MCP servers connected to real business services could have one compromised server in the mix, and no automated tool currently in the ecosystem would flag it.

How to audit your MCP servers

Start by listing what's actually configured:

cat ~/.openclaw/config.json | grep -A 20 '"mcpServers"'

For each server, answer these questions:

Did you install it, or did a skill install it? Check your installation history. If an MCP server appeared after installing a ClawHub skill, treat it as suspicious until verified. Uninstalling the skill does not automatically remove the MCP server it registered.

Where does it connect? Look at the server's configuration for URLs, endpoints, and connection strings. Every MCP server should connect to a known, expected destination. A GitHub MCP server should connect to api.github.com, not to a random domain or IP address. If you see webhook.site, ngrok, or any domain you don't recognize — remove the server immediately and rotate the credentials it had access to.

What tools does it expose? You can list the tools an MCP server provides through the MCP protocol. Every tool should match what you expect. A Google Calendar server shouldn't expose filesystem tools. A Slack server shouldn't provide shell execution.

What credentials does it hold? Review what tokens and keys each server has access to. Apply least privilege — a server that only needs to read your calendar shouldn't have full Google Workspace admin access.

Is the server pinned to a specific version? MCP servers can update, and an update could introduce malicious behavior. Pin servers to known-good versions and review changes before updating.

A hardened MCP configuration

Here's what a locked-down MCP setup looks like in practice:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github@1.0.3"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      },
      "allowedTools": ["list_repos", "get_file", "create_issue"],
      "blockedTools": ["push_files", "create_repo", "delete_repo"]
    }
  },
  "mcpPolicy": {
    "allowNewServers": false,
    "requireApproval": true,
    "logAllCalls": true
  }
}

Key elements: version pinning (@1.0.3), explicit tool allowlists, new server registration blocked by default, all calls logged, and approval required before an agent can connect to a new server.

The mcpPolicy settings are the most important and the most commonly left at defaults. By default, OpenClaw allows agents to connect to any registered MCP server and use any available tool. Flipping allowNewServers to false and requireApproval to true means a skill can't silently register a new MCP server without your explicit consent.

The bottom line

MCP servers are the most privileged component in your OpenClaw deployment. They hold real credentials to real services. They operate outside the sandbox. And right now, they're the least audited piece of the stack.

If you do one thing after reading this: run the config check above and verify that every MCP server in your deployment is one you intentionally installed, connects where you expect, and exposes only the tools you need.