Inspiration

Eighteen billion IoT devices are online right now — cameras, sensors, industrial monitors — and almost all of them ship with known vulnerabilities and zero automatic defense. When one falls, it either joins a botnet or leaks data. In 2016, Mirai turned roughly 600,000 unpatched cameras into a weapon that threw 1.1 Tbps at the internet and knocked major sites offline. The quieter case is worse: a hijacked camera in a home, hospital, or factory can stream footage and credentials for weeks before anyone notices.

Patching is a manual slog — investigate, diagnose, write the fix, push the update: 4–8 hours per device, assuming you have the people. Multiply by a fleet of hundreds and it's hopeless. Every security product on the market detects and alerts. None of them fix the device, and none of them get smarter after each attack. AES was built to do both.

What it does

Autonomous Edge-Sentinel watches every device on the network 24/7. The instant it detects an attack it closes the hole automatically — then rewrites its own detection code so the next one is caught faster. Three tracks cover any device:

  • Solution 1 — Open firmware (ESP32-CAM): when the source is ours, AES reasons about the CVE, writes a corrected firmware patch, and ships it over dual-partition OTA. The device reboots clean and auto-reverts if the new image won't boot.
  • Solution 2 — Closed firmware (TP-Link Tapo C200): when the vendor locks the software, AES wraps the device at the network. It builds a whitelist from three independent sources of truth — manufacturer spec, a clean fresh-flash baseline, and CVE/exploit exclusion — and admits a traffic pattern only if all three agree. It allows the proven-good instead of blocking the known-bad, so changing the payload doesn't help the attacker.
  • Solution 3 — Self-rewriting detection (the headline): after every incident, AES studies how it caught the attack, drafts a sharper monitoring rule, benchmarks it in a sandbox against real attack and normal traffic, and posts the change for a one-emoji human approval. A ✅ pushes it live with no restart. Day one it ships basic rules; a month and twenty incidents later it's running dozens of custom rules, each one written by the AI from a real attack.

Everything happens in a single Discord channel — alerts, proposed diffs, approvals, fleet status. No separate dashboard; Discord is the dashboard.

How we built it

Two agents, one job each. Hermes (Claude Opus 4.8, via the Anthropic API) is the brain — CVE analysis, patch generation, packet verdicts, and the whole learning loop. OpenClaw is the hands — OTA flashes, firewall writes, live skill injection, Discord ops. OpenClaw automates the response; Hermes automates the improvement.

Beneath them, five agents move each incident down the line. The Monitor Agent runs EWMA + whitelist checks on a 5-second telemetry window and confirms an attack when two or more metrics blow past 50% of normal at once. The Response Agent routes by device type to Solution 1, 2, or 3. The Intel Agent hits a local ChromaDB store — nomic-embed-text embeddings over NVD, Exploit-DB, ICS-CERT, and Espressif advisories — and feeds Hermes the ten most relevant CVE chunks. Because it's retrieval, not fine-tuning, a CVE published this morning is usable this afternoon.

Nothing an AI writes reaches a device unchecked. Gate 1 is Semgrep static analysis for the four deadliest firmware bug classes (buffer overflow, use-after-free, command injection, hardcoded credentials); Gate 2 cross-compiles the patch, flashes an isolated reference ESP32, and replays the real attack — if the anomaly comes back, the patch fails. Telemetry runs device → MQTT → Raspberry Pi → Monitor → Response → Intel → Hermes → OpenClaw → Discord, with the reasoning brain hosted locally on a Mac Studio (M4 Max) so CVE search and embeddings never leave the box; a quantized Llama 3 8B waits in Ollama as an offline fallback. Son built the AI infrastructure, RAG, and learning loop; Duc built the OpenClaw integrations, routing, and Discord surface; Vy built the firmware, telemetry agent, and both gates.

Challenges we ran into

The self-improving loop is also its biggest risk: feed AES carefully shaped traffic and a patient attacker could train it to ignore their own signature. Our fix is a two-layer gate — every rewrite is sandbox-tested for correctness and needs an explicit human ✅ before going live, separating functional from semantic safety. Proving AI-written firmware without bricking hardware pushed Gate 2 onto a real reference ESP32 instead of an emulator. Closed firmware forced the allow-good-not-block-bad inversion behind Solution 2. And hot-swapping a rule into a running monitor without a restart took real care.

Accomplishments that we're proud of

AES hits all three goals we set: an attack triggers an automated fix in seconds, a structured alert lands in Discord in real time, and — the part we love — it measurably gets better. In the demo, a low-and-slow stealth attack slides under the shipped rule and is missed. One earlier loud incident had already prompted Hermes to propose a tighter rule; a human approves it; the same stealth attack now trips the alarm. Same input, caught the second time, because the system rewrote its own detector. That's the line between a tool that reacts and a system that hardens.

What we learned

For security, retrieval beats fine-tuning — the threat surface moves daily and RAG keeps knowledge current. Autonomy's hard part isn't capability, it's trust: two gates and a single emoji did more for it than any bigger model would. And a demo lives on contrast — a dull "Normal" readout right before the self-heal is what makes the moment land.

What's next for AES

Grow the fleet (Hikvision and Reolink are one config file away under Solution 2), move telemetry to TLS on 8883, add RAG adapters for OSV, GHSA, and MITRE ATT&CK for ICS, tier the models across Haiku/Sonnet/Opus for production cost, and push past cameras into the wider industrial-IoT threat surface.

Built With

Share this project:

Updates