Show HN: Clawdstrike – a security toolbox for the OpenClaw ecosystem
github.com
OpenClaw has been popping claw for weeks now…
We’ve seen the same question come up again and again: “This is fun but how do we no get fuk?”
My answer: Clawdstrike.
It’s an open-source toolbox for developers who want to ship EDR-style apps and security infrastructure to the OpenClaw ecosystem.
Disclaimer: this is an unpublished alpha (APIs will change). Beta is planned within ~7 days (aiming for Feb 10, 2026). Not audited—please treat as experimental.
Here’s my take: the first wave of “make autonomous agents safe where users are literally yoloing their entire system without even watching” is actually pretty simple.
Security needs to live at the boundary between an agent’s intent and action — the moment it tries to read/write files, patch code, call tools, or reach the network.
Not just “visibility.” Not just logs. But enforcement + proof.
What Clawdstrike gives you: - Fail-closed guards at the agent/tool boundary - Block sensitive paths, control network egress, detect secrets, validate patches, restrict tools, catch jailbreaks - A policy engine (YAML rulesets) so teams can start safe and tighten over time - Receipts + signatures (Ed25519) so wtf the agent actually did is verifiable — not a story in your log pipeline - An OpenClaw plugin so this drops into existing stacks with minimal friction
Everyone knows this turns into a forever cat-and-mouse game between model providers, agent frameworks, sandbox/runtime developers, and the adversaries. That’s the world we’re in. (boo. fuck you, bad guys.)
My hope is Clawdstrike becomes a useful foundation for people in the ecosystem: a place where developers and security people can encode + share proving strategies (guards, policies, verification patterns) instead of each team re-learning the same lessons in private.
Threat model (explicit, so nobody gets misled): Clawdstrike enforces policy at the agent/tool boundary. It is *NOT* an OS sandbox and does *NOT* intercept syscalls. If an agent can bypass the tool layer and touch the filesystem/network directly, gg, Clawdstrike can’t stop it. The intended setup is: pair this with OS/container sandboxing when you need syscall-level isolation (seccomp/gVisor/Firecracker/etc).
Why I’m posting: I want to do whatever I can to help build out the shared safety layer for the OpenClaw ecosystem. If this looks useful to you: clawdstrike is something you can adopt early and extend, help us help you build serious security/EDR-grade infrastructure on top of it.
Feedback I’d love: - Which single failure mode scares you most with OpenClaw today? - (exfiltration, destructive writes, supply-chain via patches, prompt/tool injection, credential leakage, lateral movement, etc.) - If this becomes a shared safety layer, what needs to be stable? - Unfortunately for you all I’ve never built a widely adopted open source security sdk, so really just looking for feedback on release cadence and stability from those who would plan on using something like this. Policy schema? guard API? receipt format? verification tooling? (Which thing must not break?) - What would make you trust it? - Formal threat model, fuzzing, reproducible builds, third-party audits, or just battle-testing? Do you want receipts to be human-legible or machine-verifiable first? (And if machine-first: what format would you want. JSON/JCS, CBOR, Merkle proofs, etc.) - How should policy be expressed? - Classic question…. So.. YAML? hybrid? - What other integrations would you like to see next?
Repo/docs: https://github.com/backbay-labs/clawdstrike
If you’re building with OpenClaw and security is on your mind, I’d love to collaborate and make this genuinely useful.