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.

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.

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.

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.