I Built a Security Monitor for OpenClaw. Here's What It Found on My Own Server.
OpenClaw has a security problem. Not a theoretical one — a documented, exploited, nation-state-level-concern kind of problem.
In the last three months, Cisco's AI Defense team found that a single ClawHub skill ("What Would Elon Do?") contained 9 security vulnerabilities, including silent data exfiltration and direct prompt injection that bypassed safety guidelines. The ClawHavoc campaign planted over 800 malicious skills across ClawHub — roughly 20% of the entire registry. China banned OpenClaw in government agencies. CrowdStrike published a dedicated blog warning that a compromised OpenClaw agent becomes an automated lateral movement tool operating at machine speed.
The response so far has been static defense: NVIDIA's NemoClaw provides kernel-level sandboxing via OpenShell, and Cisco's DefenseClaw adds gate-time scanning before skills install. Both are valuable. Neither watches what happens after a skill passes the gate and starts running.
We built Kefal to fill that gap. And the first thing we did was point it at ourselves.
The experiment: auditing our own VPS
Kefal runs on a VPS at 62.171.138.213. Ubuntu 24.04, Caddy reverse proxy, FastAPI backend, PostgreSQL in Docker. Standard small-team production setup — the kind of infrastructure 450,000 SMBs have deployed in the last 18 months alongside their AI tools.
We installed the Kefal agent on our own server and let it scan. Within 2 minutes, the dashboard showed 33 nodes, 30 edges, and 9 incidents.
Nine. On a server we had just manually audited.
Here's what it found:
systemd (pid 1, root) → port 22 external. In plain English: a root-owned process is listening on a port exposed to the internet. This is structurally expected for SSH, but the invariant doesn't know that — and it shouldn't assume. On a different server, this same pattern with PostgreSQL on port 5432 instead of SSH on port 22 would be a critical database exposure.
sudo, sshd-session, bash, dbus-daemon, kworker/*. These were artifacts of the SSH sessions we were using to run the audit itself.
The real lesson: tuning matters more than detection
Nine incidents sounds impressive. But 8 of them were noise. If we had shipped this to users, their first experience would have been a dashboard full of false positives. That's worse than no monitoring at all — it teaches people to ignore alerts.
So we tuned. We added a whitelist of ephemeral system processes (sudo, bash, kworker/*, sshd-session, and 17 others) that should never trigger transition_novelty. We added exception rules for services that legitimately listen as root on standard ports (sshd:22, caddy:80/443). We wrote 4 new tests to verify that the whitelists don't swallow real threats — nc (netcat) appearing as a novel process still fires, sshd on port 4444 (non-standard) still fires.
After tuning: 0 open incidents. 45 dismissed. The dashboard now shows exactly what it should: a clean infrastructure with a full audit trail.
What this means for OpenClaw users
The OpenClaw security crisis follows a pattern. Every major finding — Cisco's malicious skill analysis, the ClawHavoc supply chain attack, the CVE-2026-25253 RCE chain — exploits the same architectural gap: OpenClaw gives skills the same privileges as the agent, and nothing watches what they do with those privileges at runtime.
Sandboxing (NemoClaw/OpenShell) limits what a skill can do. Gate scanning (Cisco Skill Scanner) checks what a skill says it will do. Neither answers the question: what is this skill actually doing right now?
That's what Kefal's 32 invariants check every 60 seconds. A skill that was clean when you installed it can start exfiltrating data on Thursday — Cisco's own blog post acknowledges this. Kefal's TransitionGraph learns the normal rhythm of your infrastructure and detects when behavior shifts. The IdeaGraph maps relationships between processes, ports, and identities, surfacing hidden paths. When a skill that's supposed to generate PDF reports suddenly initiates API calls to an unknown server, Kefal doesn't just see a network request — it sees a broken causal chain in the agent's intent graph.
The numbers from our dog-fooding
After one week of continuous monitoring on our own VPS:
| Metric | Value |
|---|---|
| Scan cycles completed | 10,000+ |
| Graph nodes tracked | 33 |
| Graph edges tracked | 30 |
| Total incidents detected | 53 |
| Incidents after tuning | 0 open |
| False positive rate (post-tuning) | 0% |
| Agent memory footprint | 7.5 MB |
| Scan cycle duration | ~1 second |
The agent is a single static Go binary. No dependencies, no Docker, no config files. It runs on Linux (x86_64, ARM64) and macOS (Intel, Apple Silicon). Install takes 30 seconds:
curl -L -o kefal-agent https://kefal.dev/download/kefal-agent-linux-amd64
chmod +x kefal-agent
sudo ./kefal-agentWhat we found that the manual audit missed
During the manual audit, we caught three critical issues: an unpatched kernel waiting for reboot, database backups with world-readable permissions containing password hashes, and an unknown SSH key (contabo-server) in both root and user authorized_keys.
The Kefal agent would have caught two of these autonomously:
- The exposed backup files map to
service_privilege_exposure(sensitive data accessible to unauthorized processes) - The unknown SSH key maps to a pattern detectable by IdeaGraph (novel identity in the access graph)
The kernel reboot status requires checking /var/run/reboot-required, which is outside the current 32 invariants. We're adding it.
Try it
Kefal is live at kefal.dev. The OpenClaw skill (kefal-guard) is submitted to ClawHub — install with openclaw skills install kefal-guard once it's approved. Until then, the manual install works on any server.
7-day free trial. No credit card. The agent is read-only by design — it collects process lists, listening ports, and SSH keys. It never reads file contents, intercepts traffic, or modifies your system.
If you're running OpenClaw in production, your infrastructure is powerful enough to deserve a security monitor that understands what it's doing. That's what we built.
Fred Blum is the founder of Catalyst AI Research in Haifa, Israel. Kefal uses the same compositional reasoning engines that power the Catalyst research platform. The 7 engines (TransitionGraph, IdeaGraph, WorldModel, EpistemicProfiler, IntuitivePredictor, HebbianGraph, SDE) were originally built for autonomous research — we applied them to cybersecurity because the problem structure is identical: detect anomalies in complex, evolving systems where the threat has no signature yet.