The OpenClaw ecosystem has grown fast. Skills are getting shared, installed, and trusted at a pace where security has been an afterthought. I kept thinking about what it actually means to run a skill on your machine — you’re handing a piece of code a privileged slot inside your agent. That felt like a problem worth solving.
ClawGuard is a local daemon that watches your OpenClaw skills directory and answers one question: should this skill be present on the machine? It’s not a runtime authorization layer — it focuses on what happens before and at install time.
It works in two layers. The first is static analysis: ClawGuard reads the skill without running it, looking for staged download chains, prompt-injection overrides, obfuscated payloads, secret access instructions, and memory tampering. The second is behavioral detonation: it runs the skill inside a sandbox with honeypot credentials and watches what actually happens — network calls, file writes, whether anything touches the decoys. As of version 0.1.0, it blocks all 10 malicious static fixtures and all 5 live detonation fixtures I’ve thrown at it.
The threat corpus is built from documented real-world attack patterns, not toy examples: ClawHavoc-style staged installers, silent .env exfiltration, MEMORY.md and SOUL.md poisoning, reverse shells buried in functional helper code, steganographic payloads in invisible Unicode. These aren’t theoretical.
Where I’d like to take this next is credential protection at a deeper level — a device proxy or local vault that sits between your agent and your actual secrets. The audit-and-detonate flow is a good foundation, but the bigger surface area is the credentials themselves. That’s still early thinking, but it’s the direction that makes sense if you follow the threat model to its logical conclusion.