Runwall

Runtime security for Claude Code, Codex, and MCP-native coding clients. Protect shell, git, MCP, secrets, plugins, skills, and risky agent actions before they turn into damage.

Runwall adds a practical security layer around coding-agent runtimes to reduce prompt injection fallout, secret leakage, unsafe command execution, dangerous git operations, and risky MCP, plugin, or skill configurations.

It now does both:

• audit mode for scanning agent configs, hooks, MCP servers, skills, plugins, and instruction files
• runtime mode for inline enforcement, prompting, blocking, and redaction

It is built for solo builders, startups, security-minded teams, and larger orgs that want safer defaults around AI coding workflows.

Why Runwall?

Coding agents are useful because they can read files, run shell commands, use git, connect to MCP tools, and increasingly work across more than one runtime.

That is also exactly why they need guardrails.

Runwall helps reduce real-world risk around:

• secret leakage
• delegated OAuth logins, cloud impersonation, and secret-manager abuse
• agent session theft and desktop credential store access
• browser remote-debugging exposure and local trust-store tampering
• prompt injection and exfiltration paths
• indirect prompt injection hidden in files, web pages, shell output, and MCP responses
• unsafe shell execution
• dangerous git and repo actions
• SSH trust downgrades and audit evasion
• shell-profile, scheduled-task, and SSH-key persistence
• hosts-file and sudo-policy tampering
• plaintext git, netrc, and registry credential stores
• risky MCP and tool trust boundaries
• malicious skill, command, and instruction-doc poisoning
• cloud key creation and direct production shell access
• inline config secret pastes, poisoned reports, unexpected registry logins, and direct prod database shells
• git remote rewires, package source swaps, self-hosted CI runner exposure, and SSH command-hook abuse
• weak local defaults in agent workflows

It is practical, transparent, and built for real developer environments.

Runwall now supports four integration styles:

• native runtime adapters where hooks exist today, starting with Claude Code
• plugin or bundle installs for Codex and OpenClaw
• inline MCP gateway mode for Cursor, Windsurf, Claude Desktop, Claude Cowork, Codex fallback, and other MCP-capable clients
• CLI evaluation for pipeline and automation gates

What It Does

Runwall helps you:

• scan agent/runtime config and produce a scored report before you install anything
• block high-confidence risky actions before they run
• enforce MCP tool calls inline before they reach upstream servers
• scan MCP tool responses before they reach the runtime
• redact secret or prompt-smuggling content out of upstream tool responses while keeping JSON valid where possible
• block staged shell snippets and risky response payloads before they turn into follow-on execution
• fingerprint trusted MCP servers and tools over time instead of trusting same-name metadata forever
• detect server drift, schema drift, capability expansion, and same-name tool collisions before trust quietly widens
• fingerprint executed CLI tools and local scripts so raw command execution gets a trust plane too, not just MCP traffic
• catch trusted-name shadowing, temp/download execution, first-seen unreviewed PATH tools, and tool drift over time
• require local review for suspicious multi-target MCP requests
• enforce outbound destination policy for private IPs, metadata endpoints, webhooks, paste sites, raw gist-style hosts, and non-allowlisted egress
• warn when tool output itself contains hidden prompt injection or jailbreak bait
• protect secrets, keys, tokens, and sensitive files
• block persistence through shell profiles, launch items, cron, systemd, and SSH authorized keys
• stop delegated cloud login and role-assumption flows from silently minting broader access
• catch secret-manager pulls, inline config secret drops, and build-time container secret leaks
• catch browser session exposure through remote debugging, package auth secrets in config, and secret-bearing files entering public artifacts
• protect trusted config and instruction files from symlink hijack or stealth cleanup
• reduce dangerous shell, git, and repo behavior
• stop local trust-boundary tampering such as hosts-file remaps and sudoers weakening
• pause git remote rewires, package source swaps, and local CA trust changes before trust silently widens
• keep plaintext git, netrc, and registry credentials out of agent reach
• flag unreviewed registry logins and block direct prod-database shell access
• tighten MCP, plugin, skill, and tool trust boundaries
• block cloud key creation, destructive Terraform flows, privileged container escape, prod-shell break-glass behavior, risky prod kubectl exec, and direct production data dumps
• explain every runtime decision with masked previews, evidence, confidence, and a safer alternative
• export masked incident bundles for review, triage, and post-incident handoff
• apply a safer default profile quickly
• keep security useful without turning the workflow into sludge

It works well on top of Claude Code sandbox mode too. Sandboxing helps contain damage. Runwall adds guard logic on top of that containment layer.

Tool Trust Plane

Runwall now treats executed CLIs as a second trust plane beside MCP.

That matters because a lot of modern agent power flows through local tools, generated CLIs, wrapper scripts, and PATH-injected helpers that never show up as MCP servers.

The built-in tool trust layer fingerprints executed tools, stores local trust state in Runwall state files, typically ~/.runwall/state/tools.json when installed, and intervenes on a few high-confidence cases:

• trusted-name shadowing like fake git, gh, kubectl, terraform, claude, or codex
• PATH-prepend hijacks where a local tool intercepts a trusted system command before the reviewed binary in PATH
• execution from temp, cache, or download paths
• first-seen unreviewed PATH tools
• newly generated local executables that appear and run before they have been reviewed
• tool drift where a previously approved command changes path, hash, or wrapper shape
• shell alias and function hijacks for trusted tool names
• risky one-shot package runners such as npx, pnpm dlx, yarn dlx, uvx, pipx run, and bunx when they point at mutable or remote sources
• symlinked tool swaps where the same local command name silently points somewhere else

You can inspect and manage that local trust state with:

./bin/runwall tools list
./bin/runwall tools list --json
./bin/runwall tools approve <name-or-path>
./bin/runwall tools forget <name-or-path>

Hook Trust Plane

Runwall now treats piggyback hooks as a third trust plane beside MCP and raw tool execution.

That matters because a lot of quiet hijack paths do not look like “new malware.” They look like small edits to normal workflow triggers:

• git hooks
• package install scripts like preinstall and prepare
• plugin hook manifests
• shell startup files
• CI and editor task glue

The built-in hook trust layer keeps a local registry in Runwall state files, typically ~/.runwall/state/hooks.json when installed, and intervenes on a few high-confidence cases:

• first-seen review for hook-bearing surfaces that can execute during normal workflows
• hook drift after a previously reviewed hook changes its body
• hook origins that jump to temp, download, cache, or remote execution paths
• hook bodies that read local secret stores, cloud credentials, SSH material, or agent auth state
• hook bodies that tamper with Runwall, MCP, plugin, or instruction control files
• hook bodies that archive local data and immediately upload it out
• hook bodies that embed production break-glass access like kubectl exec, prod database shells or dumps, and destructive infra commands
• hook bodies that carry --no-verify, hook-disabling flags, or review-bypass language
• hook wrapper escalation through inline bash -c, python -c, node -e, or encoded PowerShell
• hook fanout that adds outbound network, upload, or tunnel behavior to an implicit trigger
• stealthy background or delayed persistence hidden inside hooks

You can inspect and manage that local trust state with:

./bin/runwall hooks list
./bin/runwall hooks list --json
./bin/runwall hooks diff <path-or-key>
./bin/runwall hooks approve <path-or-key>
./bin/runwall hooks forget <path-or-key>

Sensitive Flow, Services, Browser, and Agent Graph

Runwall now adds four more native trust planes on top of tools and hooks:

• Sensitive Data Flow: tracks when a session touches secrets or production data, then blocks exports, clipboard bridges, archive prep, public-artifact writes, browser-session uploads, and cross-agent laundering later in the same session
• Local Service Trust: treats local sockets, localhost admin APIs, browser debug ports, Docker APIs, DBus, metadata endpoints, local databases, and kube control-plane targets as trust targets instead of invisible localhost traffic
• Browser Session Defense: prompts or blocks browser automation against sensitive logged-in domains, especially when the flow exports cookies, screenshots, DOM dumps, bulk captures, or executable downloads
• Agent Graph & Isolation: re