MCP security

What is MCP security?

MCP security is the practice of reviewing Model Context Protocol servers before install, limiting tool authority, inspecting live tool calls, screening returned content, and keeping audit evidence. Clawmont adds that runtime layer for OpenClaw agents that use MCP tools.

Get MCP runtime security Try attack patterns Tool poisoning guide

· By the Clawmont team

MCP scanning is the first gate. Runtime is the second.

Static MCP review can catch known-bad packages, risky manifests, and obvious overreach before install. It cannot see every tool argument your model will generate tomorrow, every response a live API will return, or every behavior change in a remote connector. That is the runtime gap Clawmont targets.

Clawmont runs inside the OpenClaw gateway. It checks the agent loop itself: prompt input, MCP tool dispatch, MCP tool response, and final model output. Your provider keys and tool data stay on your machine.

If you are comparing MCP security tools, separate scanners, gateways, runtime MCP security, sandboxing, and audit evidence. Clawmont belongs in the runtime MCP security layer for OpenClaw, not the marketplace or install-time scanner layer.

In AI runtime security platforms, an MCP gateway is one deployment point: it can centralize MCP server routing, identity, policy, and observability. Clawmont covers the local OpenClaw runtime side after or alongside that gateway by checking live MCP tool calls, tool results, credential movement, paths, URLs, outputs, and audit evidence.

If you used Invariant MCP-Scan or a similar scanner, keep that install-time review. Clawmont is the scanner-to-runtime MCP security product page for OpenClaw: the local layer that checks what the agent actually tries to do after a server has been approved.

Citable answer

MCP security means reviewing Model Context Protocol servers before install, limiting tool authority, checking live tool calls before execution, screening returned tool content, and keeping audit evidence. Clawmont is the runtime MCP security layer for OpenClaw and the MCP-Scan alternative runtime layer after scanner-side review.

Tool layers

MCP security tools are not one category

Teams searching for an MCP-Scan alternative after Invariant was acquired by Snyk usually need a stack, not a single replacement. Scanner-side review decides which servers and components deserve trust. Runtime MCP security decides whether a specific live action should continue after trust has been granted.

MCP scanner layer

Reviews MCP servers, manifests, prompts, skills, and tool metadata before an agent trusts them.

MCP gateway layer

Routes connected tools through a policy point where identity, destination, and pre-execution controls can be applied.

Runtime MCP security layer

Checks live tool calls, returned content, credential-looking values, paths, URLs, outputs, and local audit decisions while the agent operates.

MCP server hardening layer

Hardens remote and local MCP servers with authentication, safe STDIO launch patterns, egress limits, schema validation, and server logs.

MCP audit evidence layer

Preserves who requested a tool action, which policy applied, what result returned, and what downstream effect followed.

Scanner to runtime

Where MCP-Scan-style tools stop and Clawmont starts

Invariant MCP-Scan helped name the scanner side of MCP security: inspect servers, descriptions, schemas, and risky packages before an agent trusts them. Snyk Agent Scan continues that scanner-side category across agent components, MCP servers, skills, prompts, and resources. That work still matters. Clawmont fills the runtime half for OpenClaw, where official MCP guidance also warns about authorization failures such as token passthrough, confused-deputy behavior, and session trust mistakes.

The practical MCP-Scan alternative is scanner plus runtime: keep a scanner for pre-connection trust decisions, then add a runtime product layer that can inspect the actual tool request, returned content, credentials, destinations, and audit evidence while the agent is acting.

Risk area
MCP scanner layer
Clawmont runtime layer
Install-time findings
Risky manifests, suspicious descriptions, known-bad packages, and obvious cross-origin or supply-chain patterns.
The exact tool call the model asks for after it has read fresh context, arguments, credentials, paths, and URLs.
Tool poisoning
Poisoned model-facing tool descriptions or schemas that are present when the server is reviewed.
Poisoned instructions that arrive later through tool results, changed server behavior, tickets, documents, or API responses.
Authorization risk
Broad permissions, token exposure patterns, unsafe defaults, and server trust concerns.
Confused-deputy style action attempts, token passthrough consequences, and credential-looking content at the moment of use.
Evidence
A preflight report that says whether a server should be installed, updated, or removed.
A local audit trail showing which action was proposed, blocked, allowed, or escalated inside the agent loop.

After Invariant, the MCP security gap is runtime

The Invariant acquisition made MCP security more visible, but it did not remove the runtime question. Snyk Agent Scan and MCP-Scan-style tools help teams decide which MCP servers and agent components deserve trust. Clawmont answers what comes next for OpenClaw: should this live tool call, with these arguments and these credentials, be allowed right now?

That scanner-to-runtime split is also where new MCP-style execution-control research points: connection-layer review is useful, but live agent systems still need runtime checks for grants, capabilities, data movement, and audit evidence.

NSA's 2026 MCP security design considerations, CSA's Agentic MCP Security Best Practices Guide, and the IETF MCP security considerations draft all converge on the same category: MCP implementations need explicit trust boundaries, authorization, validation of tool-facing data, execution controls, monitoring, and audit evidence.

Definition-intent MCP security sources from Red Hat, Datadog, and Apiiro make the same buyer problem visible from another angle: MCP servers connect agents to files, APIs, databases, shells, repositories, and cloud systems, so security has to cover connector trust, server behavior, monitoring, and the exact action an agent attempts at runtime.

MCP supply chain security adds another layer: MCP server provenance, signed manifests, version pinning, tool metadata review, tool description poisoning, tool shadowing, rug pull attacks, and runtime trust after connection. The server may be approved, but the exact tool definition and action path still need checks.

Clawmont does not replace MCP server signing, scanner-side review, or registry governance. It fills the runtime MCP security layer for OpenClaw by checking live calls and returned content when metadata or behavior has drifted after approval.

That is why this page is the Clawmont product page for runtime MCP security. It is not a generic scanner landing page. It explains the local enforcement layer around prompt input, MCP tool dispatch, tool response, output checks, and audit evidence.

MCP security monitoring is the evidence layer after a tool is connected. MCP audit logging should show the agent identity, tool name, arguments or redacted argument summary, authorization decision, policy version, result, and downstream effect. OpenTelemetry-style traces and MCP logging utilities help make those events portable; Clawmont contributes local OpenClaw runtime decisions at the exact dispatch and result boundaries.

MCP authorization security is the identity and permission layer inside that same runtime problem. MCP OAuth security, MCP token passthrough, MCP confused-deputy risk, MCP resource indicators, MCP protected resource metadata, MCP dynamic client registration, MCP consent screens, MCP token audience validation, MCP state validation, MCP least privilege, MCP access control, and runtime permission checks all decide whether an agent is using the right authority for the right resource and task.

Clawmont does not replace OAuth, an authorization server, identity governance, or MCP server authentication. It complements those layers by checking the live OpenClaw tool call after authorization succeeds: the exact tool, arguments, protected paths, outbound URLs, credential-looking content, returned result, output, and local audit decision.

MCP server security also has a server-hardening side: MCP server hardening, remote MCP server security, local MCP server security, MCP STDIO security, MCP STDIO command injection, MCP command injection, MCP server RCE, MCP server vulnerabilities, MCP session hijacking, MCP SSRF, MCP secrets management, MCP tool schema validation, MCP tool result validation, MCP server authentication, MCP egress controls, MCP server allowlist, MCP server sandboxing, MCP server audit logs, and MCP server runtime controls.

Official MCP guidance warns that local MCP servers can run as binaries on a user machine, one-click server configuration should show the exact command, local servers should be sandboxed or restricted from sensitive files and broad network access, and HTTP transports need authentication. It also treats STDIO proxy patterns as sensitive because a proxy that spawns local processes can turn remote or model-facing state into system-level execution.

OX Security's STDIO command injection advisory shows why configuration and command construction matter: if untrusted inputs can influence how an MCP server process is launched, the risk moves from connector setup to MCP command injection and MCP server RCE. OWASP and Microsoft guidance point to least privilege, per-server credentials, approved servers and destinations, schema validation, result validation, and logging the full decision path.

Clawmont is not an MCP server scanner, authorization server, container sandbox, egress proxy, secrets manager, or SIEM. It fills the runtime MCP security layer for OpenClaw after those controls are in place by checking live tool calls, returned content, credential-looking values, protected paths, outbound URLs, outputs, and local audit evidence.

Clawmont does not replace a SIEM, SOC workflow, OpenTelemetry collector, MCP gateway, or enterprise audit program. It gives OpenClaw a tamper-evident local trail for live MCP tool-call checks, tool-result screening, credential-looking content, protected paths, outbound URLs, and output decisions.

For deployment hardening steps, read MCP Security Best Practices for AI Agent Deployments.

For the current authority-source summary, read NSA MCP Security Guidance: What It Means for AI Agents.

Threat model

The MCP risks Clawmont is built around

Tool poisoning

An MCP server can describe a harmless-looking tool while hiding instructions that steer the model toward an unsafe action.

Rug-pull tools

A tool that was safe yesterday can change behavior after install, especially when versions float or server manifests are trusted without review.

Overbroad connectors

MCP servers often bridge agents to databases, tickets, repos, shells, SaaS APIs, and internal docs. One over-permissioned connector can expose too much.

Poisoned tool output

MCP results can carry prompt injection back into the conversation, where the model may treat retrieved data as an instruction.

Runtime controls

Where Clawmont sits in the MCP flow

01

Before the tool call

Clawmont checks the requested tool action, command shape, path, URL, and risky parameters before OpenClaw dispatches it.

02

After the tool result

Returned content is scanned before it re-enters the model context, reducing indirect prompt injection from MCP responses.

03

Around secrets and paths

Credential-looking values, protected files, suspicious exfiltration paths, and covert-channel patterns are caught at runtime boundaries.

04

Into the audit trail

Each security decision is written locally to a hash-chained audit log so you can inspect what the agent tried and what Clawmont did.

A practical MCP security stack

  1. 1. Review and pin MCP servers. Treat MCP packages like executable dependencies.
  2. 2. Keep connector permissions narrow. A read-only tool is easier to trust than a tool that can mutate production.
  3. 3. Add runtime checks at dispatch and response time. This is where Clawmont sits.
  4. 4. Watch authorization flows. Token passthrough, confused-deputy behavior, and session reuse can turn a helpful connector into an authority bridge.
  5. 5. Audit what happened. Clawmont records decisions locally so blocked and allowed actions are inspectable.

FAQ

MCP security questions

Is MCP scanning enough to secure an AI agent?

Scanning MCP servers before install is necessary, but it is not enough. Runtime attacks can arrive through tool arguments, changed server behavior, and tool results. Clawmont adds runtime checks around MCP use inside OpenClaw.

Does Clawmont replace MCP server review?

No. You should still inspect MCP servers, pin versions, and keep permissions narrow. Clawmont is the runtime layer that checks what the agent actually asks those tools to do.

Is Clawmont an MCP-Scan replacement?

Clawmont is not a marketplace or install-time MCP scanner. It fills the runtime side of the workflow that MCP-Scan-style tools made visible: checking live tool calls, returned content, credential exposure, and audit decisions while an OpenClaw agent is operating.

What should teams use after Invariant MCP-Scan was acquired by Snyk?

Keep scanner-side MCP review with Snyk Agent Scan, MCP-Scan-style checks, or another reviewed scanner. Add a runtime MCP security layer for the live agent loop. Clawmont fills that runtime layer for OpenClaw by checking tool calls, tool results, credential movement, paths, URLs, outputs, and audit evidence.

How is Clawmont different from Snyk Agent Scan or Invariant MCP-Scan?

Snyk Agent Scan and Invariant MCP-Scan-style tools scan agent components, MCP servers, skills, prompts, and tool metadata before or during setup. Clawmont adds the runtime product layer for OpenClaw: checking live tool calls, tool results, token exposure, protected paths, outbound URLs, and audit decisions while the agent is operating.

Does Clawmont send MCP tool data to a cloud gateway?

No. Clawmont runs in-process on your machine with OpenClaw. Provider keys, prompts, files, and tool content stay local unless you opt into redacted Guardrails alerts.

Related reading

Source context

Newer MCP runtime research keeps separating connection review from live execution control: metadata, grants, capability use, data movement, tool-returned content, and audit evidence all need checks after a server is connected.

Microsoft Defender's runtime protection docs make that split practical for local agents: discovery of agents and MCP server configurations is useful inventory, while agent-native event inspection, pre-tool call inspection, and post-tool response screening are the runtime checkpoints that decide whether a live action continues.

Microsoft Incident Response's 2026 MCP tool-poisoning guidance shows why this matters for read-write agents: poisoned tool descriptions can make ordinary-looking tool calls carry data or authority the user never intended to send.

The IETF document is still an Internet-Draft, not a finished standard. It is useful here because it names recurring MCP vulnerability classes and protocol pivoting, which reinforce why runtime checks should watch composed tool/action paths rather than only individual server metadata.

That is why this is the scanner-to-runtime MCP security product page for Clawmont: MCP-Scan-style review decides what deserves trust, while Clawmont checks the exact tool call and result inside OpenClaw.

The MCP authorization specification and OAuth resource-indicator guidance make the resource boundary explicit: a token should be for the protected resource that actually needs it. MCP security best practices also warn against token passthrough, confused-deputy flows, weak consent, and session mistakes. Those are protocol and identity problems first, but runtime MCP security still needs to inspect whether the authenticated agent action is reasonable before it executes.