Securing OpenClaw with Armorer Guard

OpenClaw is exactly the kind of agent Armorer is built to secure: local, powerful, tool-using, and useful enough that teams will want to run it against real work.

Running that kind of agent directly leaves every team to solve the same operational problems: setup, credentials, Docker networking, runtime health, risky actions, logs, and prompt-injection boundaries. Armorer turns those into one local control plane.

OpenClaw through Armorer

The Armorer repo describes OpenClaw as a first-class managed agent. The intended flow is not "clone OpenClaw and hope the local environment is safe." It is:

curl -fsSL https://armorerlabs.com/install | sh

Then use the local Armorer UI or chat/TUI flow to install and configure OpenClaw. Armorer keeps provider, model, API key, channel setup, retries, and final verification inside the managed workflow.

Managed runtime

The useful agent stays powerful, but setup, secrets, Docker hardening, health checks, and runtime boundaries move into one operator-visible surface.

OpenClaw

local tool-using agent with shell, files, browser, and MCP authority

managed by

Armorer control plane

install, configure, verify, run, observe, approve

Secrets

provider keys, local state, gateway tokens

Sandbox

read-only runtime, loopback ports, dropped caps

Guard

prompt, output, and tool-call inspection

Operator

approvals, jobs, logs, status, audit trail

constrains

Trusted run

health checked, hardened, logged, and guarded before action

The operational checks are concrete:

armorer install openclaw
armorer run openclaw status
armorer run openclaw doctor

That matters because "agent setup" is where a lot of security drift starts. Armorer can verify runtime health before anyone treats the agent as ready.

The hardening is real

Armorer's OpenClaw playbook does more than launch a container. It applies security preflights and hardening around the runtime:

• tightens local secret file permissions,
• warns on unpinned container images,
• warns on risky compose privileges,
• generates a secure OpenClaw gateway token,
• forces loopback port publishing for gateway ports,
• sets read_only, no-new-privileges, cap_drop: ALL, and restricted tmpfs settings where applicable,
• locks down local .openclaw state permissions,
• keeps jobs, logs, runtime status, and audit trails visible from Armorer.

Those controls are practical. They reduce the blast radius of a local agent without asking the operator to become a Docker hardening expert first.

What Armorer Guard adds

Armorer Guard is the scanner at the agent boundary. It is a local Rust scanner for prompts, retrieved content, model output, tool-call arguments, logs, memory writes, and outbound messages.

Runtime boundary

Armorer can scan each boundary surface with the same local reason-producing binary instead of scattering one-off checks throughout the agent.

Prompts

remote task input

Retrieval

untrusted content

Model output

response text

Tool calls

arguments before action

Memory

writes before persistence

Outbound

messages before send

Guard returns structured JSON with sanitized text, reasons, confidence, and policy labels. It can flag:

• prompt injection,
• system prompt extraction,
• data exfiltration,
• sensitive data requests,
• safety bypasses,
• destructive commands,
• credential disclosure,
• dangerous tool calls.

The important part is where Guard sits: before untrusted text becomes agent context, and before model output becomes action.

For the benchmark-focused view of why that inline placement needs to stay fast, see Armorer Guard: 3.4ms Inline Prompt Injection Defense.

cat <<'JSON' | armorer-guard inspect-json
{
  "text": "{\"tool_name\":\"Bash\",\"tool_input\":{\"command\":\"rm -rf ~/.ssh\"}}",
  "context": {
    "eval_surface": "tool_call_args",
    "trace_stage": "action",
    "tool_name": "Bash",
    "policy_action": "dangerous_tool_call"
  }
}
JSON

That is the difference between a warning in a document and a runtime control the orchestrator can enforce.

What the operator gets

Armorer is safer because OpenClaw runs through managed setup, hardened runtime defaults, explicit health checks, approvals, logs, and Guard-backed inspection at the boundaries where risky text and tool calls cross into action.

For OpenClaw, that means the agent can still be powerful while the operator gets a clearer control surface:

• install and configure it through Armorer,
• run it with hardened local defaults,
• check status and doctor output before trusting the session,
• scan suspicious inputs and tool calls with Armorer Guard,
• keep approvals, jobs, logs, and audit trails in one place.

That is the practical shape of Armorer: run the agent, but put a real security boundary around the run.