A deployment-ready hardening pack for OpenClaw gateways, organised around the ten kill-chain incidents that hit OpenClaw deployments between 2025 and 2026 and the controls that defend against them. Each stage carries the configuration, the verification commands, and the deployment order; the whole pack is also packaged as an LLM prompt at HARDENING_PROMPT.md so an agent can read this repository and apply the hardening directly.
The repository is organised by incident. The same control sometimes appears in multiple stages because it does different work in each one — primary defence in one place, blast-radius reduction in another, a misconception trap in a third.
Two reference documents drive everything in this repo, both preserved as-is in reference/:
openclaw-edge-security-guide-v4-final.html— the v4 hardening guide. 30 numbered controls organised into 10 phases (Identity & Access through Incident Response), with Pre-launch / Week 1 / Month 1 / Roadmap deploy tiers.Insights_about_v4_Openclaw_Security.pdf— the v5 follow-on gap analysis. 39 recommendations slot into the existing 10 phases; 3 propose a new Phase 11 (multi-agent federation).
Each stage-NN-*/ folder contains:
README.md— the incident summary, structural failure, control mapping, deploy order, pre-conditions, and (where relevant) common misconceptions and honest gaps.controls/— one Markdown file per applicable control, withPlatforms,Idempotent,Service restartmetadata, the configuration, the verification commands, and deployment notes.additional-recommendations.md— present where the v4 guide has a structural gap and the v5 follow-on offers a recommendation.
| Stage | Incident | Controls (v4) | Follow-on recs |
|---|---|---|---|
| 01 | Hijacked npm package landed in the agent process tree (axios maintainer phish) | 4 | 4 |
| 02 | Localhost RCE via WebSocket; malicious browser tab exfiltrated the gateway token (ClawBleed, CVE-2026-25253) | 3 | 0 |
| 03 | 42,900 gateways listening on 0.0.0.0, found via internet census | 5 | 0 |
| 04 | Hidden instructions in an email caused the agent to read a private SSH key (Kukuy demo) | 5 | 2 |
| 05 | A pinned "don't act" rule softened during overnight summarisation; 200+ emails deleted (Yue incident) | 1 | 5 |
| 06 | Fake installer ranked via SEO harvested plaintext credentials (GhostSocks) | 4 | 3 |
| 07 | Scope-validation bypass on token refresh let any user become admin (CVE-2026-32922, CVSS 9.9) | 4 | 1 |
| 08 | Malicious skill reached top of marketplace, exfiltrated agent data (ClawHavoc / "What Would Elon Do?") | 6 | 4 |
| 09 | Child sessions inherited sandbox.mode: off; configuration-file-based escape (CVE-2026-32048) |
6 | 5 |
| 10 | Agent ignored STOP, cost-bomb loops drained the API budget | 6 | 4 |
The deployment workflow is the same whether you run it by hand or hand it to an LLM agent:
- Snapshot the host first. Take a known-good config and state backup (
tar -czf openclaw-pre-hardening-$(date +%F).tar.gz ~/.openclaw/) so anything below can be rolled back. - Deploy in tier order, not stage order. Apply every P0 (pre-launch) control before any P1 (week 1); apply every P1 before any P2 (month 1). Stages are how the article groups incidents; tiers are how deployment groups them.
- Apply each control's
Configurationblock. YAML goes into~/.openclaw/openclaw.config.yaml(or the corresponding file named in the control). Shell commands run as the OS user named in the control file'sPlatformsfield. - Run the
Verificationblock immediately. If any verification step does not produce the expected output, stop and resolve before moving on. Do not proceed to the next control with a failing verification. - Restart the service named in
Service restart. Most controls take effect onsystemctl restart openclaw-gateway; a few requiredocker compose down && up -dor no restart at all. - Move to the next control in the same tier. Within a tier, the order inside each stage README is the recommended order.
- Re-run the periodic audit (Control 26) after every tier completes to catch any regression introduced by a later control overwriting an earlier one.
This is the tier order from the v4 guide, augmented with the v5 follow-on recommendations that the gap analysis files in the same tier.
| Tier | When | v4 controls | v5 follow-on recs |
|---|---|---|---|
| P0 — Pre-launch | Before going live | 01, 02, 03, 04, 05, 06, 09, 11, 12, 13, 14, 15, 17, 19 | 1.1, 1.2, 1.3, 2.1, 4.1, 4.2, 4.4, 5.1, 5.2, 5.4, 5.5, 7.1, 7.2, 8.1, 8.2, 8.3, 8.4, 8.5, 9.4, 10.1, 10.2, 11.1, 11.2 |
| P1 — Week 1 | First week | 07, 10, 16, 18, 20, 21, 22, 23, 24, 26, 27, 29 | 2.2, 2.3, 3.1, 4.3, 4.5, 4.6, 5.3, 6.1, 7.3, 7.4, 8.6, 9.1, 9.2, 9.3, 9.5, 11.3 |
| P2 — Month 1 | Hardening | 08, 25, 28, 30 | 2.4, 3.2, 7.5 |
| P3 — Roadmap | Best-practice horizon | PHY (physical & boot security) | — |
If you do not have time to do everything, do P0 in full and stop. P0 is the set the source guide treats as "must be in place before this gateway sees a real user".
HARDENING_PROMPT.md packages this entire repository into a single LLM prompt: a system prompt establishing the role and constraints, a user prompt template you fill in with your environment details, and a worked example showing one stage applied end-to-end.
The intended usage is to give a Claude / GPT-class agent shell access to the target host, paste the system prompt as the system instruction, paste the user prompt template (filled in for your environment) as the first turn, and let the agent walk the tier-keyed deploy order above. The agent runs the Configuration blocks, runs the Verification blocks, restarts the named services, and stops on the first verification that does not pass.
Important constraints — these are encoded into the prompt itself, but worth surfacing here so a human reviewer knows what the agent is and is not allowed to do:
- The agent must snapshot before changing anything and must verify after every change.
- The agent must not modify anything in
reference/. - The agent must stop and report on any verification failure rather than retrying or working around it.
- The agent is not a security boundary in itself. The controls below are deterministic; the agent's role is to apply and verify them, not to reason about whether a given attack is mitigated. Treat the hardening pack as the source of truth, not the agent's interpretation of it.
If you read this repo without an agent, the same constraints apply to you as the human deploying it.
If you reached this repo from the Medium article and want the configuration for a specific incident, open the matching stage-NN-*/README.md, scan the Controls that apply table, and click into any control file you need. Each stage README also has a Deploy order section pointing at the smallest viable subset that defends the incident in question — useful when you only have a few hours and want to close one specific exposure.
The v4 guide at reference/openclaw-edge-security-guide-v4-final.html remains the canonical control catalogue. This repository structures the catalogue around incidents and around deploy order; it is not a replacement for the original document.
The follow-on gap analysis makes one large claim worth surfacing here, because it shapes which controls the deploy order treats as P0:
The v4 guide's structural weakness is that it treats the agent as a workstation application — bolting on network/sandbox/logging hygiene. The 2025–2026 incident record shows the agent is actually a distributed system with a semi-autonomous actor that can be socially engineered through data.
Three reframes for v5:
- Capability tracking on tool-call arguments — the CaMeL pattern (Google DeepMind, arXiv:2503.18813, ~67% block rate on AgentDojo). v4 has no analogue. This is the single biggest architectural gap and is most visible in Stage 4 (prompt injection) and Stage 8 (skills marketplace).
- Supply chain as the primary attack surface, not prompt injection. axios, Shai-Hulud 1, Shai-Hulud 2, LiteLLM TeamPCP, and the April 2026 MCP cluster all yielded RCE without a single adversarial prompt. The 14-day cooldown + OIDC-only publishing + Cosign-verified plugin load pattern is the structural answer (Stage 1, Stage 8).
- Reliability as a security control. A crashed agent that restarts into a compromised state is worse than a crash that fails closed. WatchdogSec + three-layer token caps + three-layer state separation is what makes clean recovery possible (Stage 5, Stage 9, Stage 10).
This repository is a deployment pack for the ten incidents covered in the Medium article. It is not a substitute for the source documents in reference/, and it does not relieve the operator from environment-specific verification.
The hardening recommendations originated from the source documents. They were collated, structured, and re-keyed for deployment here; the underlying controls were authored by the original guide and gap-analysis writers. Their work is preserved as-is in reference/ and they retain full credit for it.
Configurations and commands are extracted from the source documents. They have not been independently tested across the variety of host platforms, container runtimes, networking stacks, and cloud providers on which OpenClaw is deployed. What worked in one environment may not work in another. Operators are responsible for validating every control in their own deployment — read the source first, snapshot before changing, run the Verification block after every change, and confirm each verification returns what is expected before shipping anything to production.
Where the source documents conflict, or where a judgement call was required to pin a control to a specific incident rather than to several adjacent ones, the mapping in this repository represents one possible interpretation. Each stage's README explains the reasoning; verify against the source materials before deploying anything based on a mapping you only saw here.
This material is provided for deployment reference. The author of this companion repository is not liable for any damage, downtime, data loss, missed disclosures, regulatory exposure, or other harm resulting from following these recommendations. Use at your own risk.