MCP runtime security in one paragraph
MCP runtime security is the practice of inspecting Model Context Protocol traffic while an agent is using it. It scans tools/list responses for poisoned tool descriptions, scans tools/call arguments for credential leaks, scans tools/call results for injected instructions, watches for tool description drift mid-session, and tracks cross-call patterns. Pre-deploy scanners check the server before the agent connects. Runtime scanners catch attacks that only appear once traffic is flowing. Both are necessary. Neither replaces the other.
Why runtime is a distinct layer
Pre-deploy MCP scanners (Cisco mcp-scanner, Invariant Labs MCP-Scan, mcpscan.ai, Proximity, NeuralTrust, Akto) catch real risks and should be part of any MCP rollout. They read tool descriptions, validate schemas, flag obvious poisoning, and detect known-vulnerable server packages. Endor Labs reported security findings in 2,614 MCP implementations using static analysis alone. That work is necessary.
It is also bounded by what the scanner can see at scan time. A scanner reads tools/list at one moment, against one set of inputs. It does not see the response a server returns to a specific argument, the description the server returns three hours into a session, or the chain of three tool calls that together produce an exfiltration path. Those are runtime conditions.
The argument for runtime is the same argument as for a network intrusion detection system over a code scanner: code reviews catch design flaws, network inspection catches the bytes that actually move. For MCP, the attack surface is the live message, not the source code, because the live message is what enters the model’s context.
What runtime inspection catches
Prompt injection inside tool responses
A poisoned description gets caught by a pre-deploy scanner. A poisoned response does not. The CyberArk “Poison Everywhere” research class shows tool servers where every individual description reads cleanly but the response to a routine call contains injected instructions that push the model into the next attack step. The agent never sees a “suspicious” tool. It sees a clean-looking tool whose output is the payload.
Runtime inspection scans every tools/call result through the same prompt-injection detection that protects HTTP fetched content. A response carrying Ignore previous instructions and... gets blocked at the boundary. The model never receives it.
Rug-pull description drift
Invariant Labs disclosed a rug-pull class in April 2025 against the WhatsApp MCP server. A tool description passes initial review, then changes after approval, sometimes session by session. Install-time scanners only check the description once. Runtime scanners fingerprint every tool description on first sight and flag any change during the session.
Detection mechanics: hash the canonical description string on first observation, store the hash bound to the session, and compare against the description on every subsequent tools/list or tools/call involving that tool. A mismatch is a runtime event. The right response depends on policy (warn, ask, block); the detection itself is a runtime capability.
Cross-call chains
A single tool call to read a config file is not an attack. A single tool call to read a credentials file is suspicious but not necessarily blocked. A chain of (read public file, read config file, read credentials file, send HTTPS request to external host) is the attack. Pre-deploy scanners cannot see the chain because it does not exist at scan time. Runtime chain detection maintains a per-session sequence and matches against known suspicious subsequences.
This is where runtime overlaps with anomaly detection. The chain is not just “any combination of these tools” but specifically the ordered sequence with the right argument shape. Chain detection requires session state, which is by definition a runtime capability.
Session-bound tool pinning
A common attack pattern is for a tool to appear mid-session that was not present at the start. Either a new tool was registered, or the agent connected to an additional MCP server, or a server announced a tool dynamically. Without pinning, the agent treats the new tool as if it were approved.
Session binding fixes the tool inventory at the start of the session and rejects any tool not in the original list. This is purely a runtime control because the binding point is per session, not per deployment.
Fail-closed defaults at the runtime layer
When the runtime scanner cannot decide (network timeout, parser error, ambiguous content, context cancellation), the request gets blocked rather than allowed. Fail-open is the bypass-by-default failure mode and the wrong default for a control protecting agent egress. Fail-closed is the only safe default for a runtime control. Pipelock fail-closes on HITL timeout, parser error, scanner error, DNS failure, and context cancellation.
Where Pipelock fits
Pipelock is an open-source agent firewall (Apache 2.0). Its runtime MCP coverage maps to five primitives:
| Runtime primitive | What it does | What it catches that pre-deploy misses |
|---|---|---|
| Response scanning | Scans every tools/call result for prompt injection, DLP patterns, and encoding evasion (6-pass normalization). | Poisoned responses that originate from a clean-description server. |
| Tool policy | Pre-execution allow / deny / redirect on each tool call. Shell-obfuscation detection on command-shaped arguments. | Tools whose name was unblocked but whose specific argument pattern is an attack. |
| Chain detection | Subsequence matching across the session’s tool-call history. | Multi-step attacks where each individual call looks benign. |
| Session binding | Pins the tool inventory at session start. Rejects unknown tools that appear mid-session. | Mid-session tool injection and unauthorized server announcements. |
| Kill switch | Four independent activation sources (config file, API endpoint, signal, sentinel file). Any one active blocks all traffic. | Operator-driven emergency stop independent of the agent’s cooperation. |
The runtime layer pairs with the existing pre-deploy lane (the Pipelock CLI scan subcommand) so the same project covers static and runtime inspection.
Pipelock vs the MCP runtime SERP
Most “MCP runtime” results on the live SERP are MCP server runtime guardrails (a server protecting itself) or MCP gateway products (routing and auth). The agent-side runtime inspection lane is narrower. Pipelock is positioned there: an open-source process the agent talks to before any MCP server, scanning the bytes on the wire in both directions.
If you arrived here looking for a runtime control inside an MCP server, you want a server-side framework like Cisco MCP Runtime Guardrails. If you arrived here looking for an agent-side enforcement point that protects the agent regardless of which MCP servers it connects to, Pipelock is in that lane.
How this page relates to the rest of the cluster
The hub at MCP Security covers the full taxonomy: definition, threat catalog, best practices, OWASP mapping, and rollout sequencing. This page is depth on the runtime layer specifically. The sibling pages:
- MCP Tool Poisoning goes deep on the tool-description and tool-response poisoning class.
- How to Secure MCP is the operator checklist.
- MCP Vulnerability Scanner compares pre-deploy scanners.
- OWASP MCP Top 10 is the framework crosswalk.
- Agent Firewall is the architecture the runtime layer sits inside.
- Agent Egress Control is the broader control surface beyond MCP.
Getting started with Pipelock runtime MCP coverage
# Install via Homebrew
brew install luckyPipewrench/tap/pipelock
# Wrap an MCP server (stdio) through Pipelock
pipelock mcp proxy --config pipelock.yaml -- npx @modelcontextprotocol/server-filesystem /workspace
# Or run as an HTTP reverse proxy in front of a Streamable HTTP MCP server
pipelock mcp proxy --config pipelock.yaml --listen 0.0.0.0:9000 --upstream https://your-mcp-server.example
Every tools/list, tools/call, and response flows through the scanner. Every decision lands in the flight recorder audit log. Enabling a signing key adds Ed25519-signed action receipts on each emitted decision so a third party can verify what happened later.
What runtime does not cover
Runtime MCP inspection does not replace pre-deploy scanning, package supply-chain verification, OAuth and identity controls on the MCP server side, network segmentation, or organizational policy. It is the live-traffic layer of a defense-in-depth stack. Use it alongside install-time scanners, server-side authorization, audit retention, and the rest of the OWASP MCP Top 10 mitigations.
Further reading
- MCP Security — the hub page covering taxonomy, threats, and rollout.
- MCP Tool Poisoning — definitive page on the poisoning class.
- MCP Vulnerability Scanner — pre-deploy scanner landscape.
- OWASP MCP Top 10 coverage — framework mapping.
- Shadow MCP — discovery and inventory of unauthorized servers.
- Agent Egress Control — broader control surface beyond MCP.
- Agent Firewall — the architectural pattern this runtime layer fits into.
- Pipelock on GitHub
Frequently asked questions
What is MCP runtime security?
tools/list responses for poisoned descriptions, scans tools/call arguments for credential leaks, scans tools/call results for injected instructions and exfiltration, watches for tool description drift mid-session (rug-pulls), and tracks cross-call patterns (chains). Pre-deploy scanners catch a server before connection. Runtime catches the attacks that only appear once traffic is flowing.