Kaspersky Found 512 Bugs in OpenClaw. So I Built a Monitor to Catch AI Agents Misbehaving.

Ruslan Murtuzaliyev — Wed, 18 Mar 2026 22:35:10 +0000

How this started

I didn't plan to build a security tool. I'm a CS student in Toronto. My February plans involved catching up on assignments, maybe learning some Rust.

Then OpenClaw went viral.

If you missed it: OpenClaw is an open-source AI agent that hit 20,000 GitHub stars in 24 hours. It connects to your WhatsApp, email, calendar, terminal. It runs 24/7. It writes its own code for tasks it hasn't seen before.

Kaspersky audited it:

512 vulnerabilities. Eight critical. A researcher got into Anthropic API keys, Telegram tokens, full admin access on exposed instances with Shodan. SecurityScorecard counted 135,000+ instances on the public internet, zero auth. More than 15,000 were vulnerable to remote code execution.

820 out of 10,700 ClawHub skills were malware.

I read the Kaspersky report in my dorm and realized something basic: there's no tooling for this. Antivirus for malware, sure. Firewalls for networks. EDR for endpoints. But for AI agents running code on your machine with full disk access?

Nothing existed. So I started building...

What it does? (demo)

Aegis sits between your AI agent and your OS. It polls and diffs process trees, watches the filesystem via chokidar, and logs network activity through OS-level APIs, all in user-space, no drivers required.

It watches four things:

1) Processes:
Every spawn, every child process, every shell command. When Claude Code runs npm install, you see it. When something tries to curl a domain you don't recognize, you see that too.

2) Files:
Real-time filesystem monitoring via chokidar. What's being read, written, created, deleted. Configurable rules flag when anything touches .env, .ssh/, or your credentials directory.

3) Network:
Outbound connections, DNS lookups, data leaving your machine. This is the one that gets the most attention from testers — knowing exactly where your agent sends data.

4) Behavior:
68 detection rules match against known risky patterns. Each agent gets a trust score, 0 to 100, updated live.

The rule engine

This is where Aegis went from personal hack to something shareable. Rules are defined in a structured format, an example of what one looks like:

    yaml- id: AI012
    name: Sensitive Config Access
    category: filesystem
    severity: high
    pattern: "\\.env|\\.ssh|credentials|secret"
    description: Agent accessing sensitive configuration files
    riskModifier: 15

On startup, the loader compiles patterns to RegExp, caches them in a Map, builds a categoryIndex for O(1) lookups by category.
Rules hot-reload - edit the source, they update without a restart.

68 rules cover filesystem access, network patterns, process behaviors, and agent-specific signatures including OpenClaw.

What I got wrong:

1: Chokidar globs. I used glob patterns in ignored. Lost two days to events either missing or crashing. The issue is documented but not obvious. Function-form fixed it immediately.

2: Tautological tests. I wrote 12 tests for formatBytes, all green, looked great. A contributor pointed out every single test checked static input against static output. No edge cases. No boundaries. No negative numbers, no zero, no floats. She rewrote them into 25 tests that actually caught bugs. I merged it the same day.

3: Backdrop-filter stacking. I put backdrop-filter: blur() on 33 elements for the glassmorphism look. Frames dropped. I didn't profile for a week because the rest of the UI was "fast enough." Eventually measured it — 33 composited elements is just too many. Cut it to 5, kept the visual effect where it mattered.

4: Pushing to master. "It's just a docs change." Lint-staged v16 has a bug on markdown-only commits. CI failed. Now I have a pre-commit hook that blocks edits on master. Should have had that from the start.
My own security bugs. During a hardening pass I found HTML injection in IPC channels, path traversal bypassing file access rules, and no protection against LLM prompt injection. Three PRs, 112 new tests. If you're building anything that talks to an AI model over IPC, audit it. You'll find something.

5: My own security bugs. During a hardening pass I found HTML injection in IPC channels, path traversal bypassing file access rules, and no protection against LLM prompt injection. Three PRs, 112 new tests. If you're building anything that talks to an AI model over IPC, audit it. You'll find something.

Stack

 Electron 33       Desktop shell
 Svelte 5 (runes)  43 components, pure CSS, no UI libraries
 Vite 7             Build: ~1.5s
 Vitest 4           707 tests, 44 files
 TypeScript         Strict, incremental migration from JS
 chokidar 3.6       File watching

The main process is 28 CommonJS modules (23 core + 5 platform-specific) loaded directly by Node — no build step. CJS gets grief, but Electron's main process doesn't need a bundler, and I haven't spent a single hour debugging module resolution. I'll migrate when Electron's ESM support is stable.

The renderer is 43 Svelte components with all animations constrained to transform and opacity, GPU composited only. No layout thrashing.

IPC is batched at 1000ms. Stats use running counters, not recalculated from raw data. Startup staggers monitors at 3, 8, and 12 seconds so nothing blocks first paint. Bundle ships at 60kB gzipped JS. Idle memory sits around 180-220MB (Electron baseline + monitoring overhead).

What Aegis can't do

No kernel-level monitoring. Everything is user-space polling. A sophisticated agent or malware with privilege escalation can bypass this , Aegis won't catch what it can't observe. This is a visibility tool for understanding agent workflows, not a defense against APTs. ETW on Windows and eBPF on Linux are on the long-term roadmap.

Windows gets the most testing. macOS and Linux work — a contributor shipped the cross-platform layer in PR #37 — but I develop on Windows, so that's where the edge cases get caught first.

No rule editor UI. You edit rules by hand. The IPC is ready (getRulesByCategory() and onRulesReloaded() already exist), the frontend isn't built yet.

Single machine. No fleet management. No cloud console. Aegis is a local tool. It tells you what happened on this computer.

Monitoring, not prevention.

Will be added in future updates. But now, Aegis shows you what an agent did. It doesn't block it. If you're running OpenClaw in production, you need an isolated VM. This tool is a camera, not a lock.

Roadmap

v0.10.0-alpha  ← current

Next           Spawn hardening (child_process security)
               Rules UI (visual editor in the app)
               TypeScript migration — 9 remaining files

Later          UtilityProcess for scan loop
               Ring buffers + OOM hardening

Future         ML anomaly detection
               z-score deviation from baseline agent behavior

Long-term      ETW / eBPF kernel-level hooks
               Rust N-API modules for hot paths

The ML layer is what I keep thinking about. Pattern-matching catches known bad behavior. But what about unknown bad behavior? An agent that usually reads five files per minute suddenly reading 500, that's a deviation you can catch with statistical methods, no rule required.

Build a baseline, flag anomalies.

Try it:

git clone https://github.com/antropos17/Aegis.git
cd Aegis
npm install
npm start

Starts in demo mode with simulated agent traffic. Poke around.

Or skip install: live web demo — runs in the browser, no setup.

By the numbers:

Tests - 707 pass,0 fail
Test files - 44
Svelte components - 43
Main process modules - 28 (23 core + 5 platform)
Detection rules - 68
Known agents - 107
tsc errors - 0
any types - 0
ESLint errors - 0
Build - ~1.5s
JS bundle (gzip) - 60 kB
License - MIT

What I need

Stars matter for open-source visibility.

If this seems useful,please STAR the repo.

Beyond that: install it, break it, file issues. There are some good-first-issues if you want to contribute code. If you know an agent's risky patterns, write a detection rule, I'll review and merge.

What agent behavior would you want to detect first? Curious what rules people would write.

GitHub · Demo · Landing Page

DEV Community: Ruslan Murtuzaliyev