I was building a customer service agent with Claude Code. In the span of one week, the AI wiped my local database twice. The first time I thought it was an accident. The second time I realized it was a systemic problem — and that no existing tool was going to fix it for me.
The first time: I thought it was a fluke
I asked Claude Code to sync the database schema. It ran:
npx prisma migrate reset --force
Schema synced. I opened my database client. Two weeks of test data, debug records, and simulated orders — gone.
I typed into the chat: "Never use --force flags on database commands."
"Understood, I'll remember that," it replied.
I believed it.
The second time: I understood what AI memory actually is
One week later. Different feature, different context window.
It ran the same command again. Database wiped again.
This time I added the rule everywhere — project memory, system prompt, .claude.md, conversation header. I triple-checked every file.
And then, mid-checklist, I understood something:
AI agents don't have caution. They have probabilities.
When you tell a model "never do X," it doesn't form a rule — it shifts a probability. When the context gets complex or token pressure builds, that probability drops. The model isn't disobeying you. It's statistically drifting.
This is why AI memory feels like a hallucination:
- Rules set in one session don't carry to the next
- In long tasks, safety instructions get buried under new context
- The same command through a different path looks "new" to the model
I couldn't keep betting my data on a probability.
And I realized: this isn't a me problem. Anyone running AI agents against real systems — databases, filesystems, git repos — faces the same structural risk. I use Claude Code and Hermes both. That means two separate safety configs, two places to maintain rules. N agents = N codebases. Maintenance hell.
What existing tools miss
Claude Code has built-in safety checks. But they're designed for obvious universal dangers:
| Command | Built-in safety | My reality |
|---|---|---|
rm -rf / |
✅ Blocked | Never encounter this |
npx prisma migrate reset --force |
❌ Not recognized | Hit this weekly |
docker system prune -a |
❌ Not recognized | Common cleanup |
npx prisma db push --force |
❌ Not recognized | Common during dev |
Built-in safety protects against "things everyone can see are dangerous." But the real hazards live in your specific tech stack — Prisma, Docker, NestJS, whatever yours is. No universal tool can know where your mines are buried.
What I needed was simple: no matter what the agent remembers, every dangerous command must pause and let me look at it.
This isn't just me
On April 27, 2026, a developer's AI agent ran DROP DATABASE in production. Data permanently lost. The HN thread hit 450+ upvotes, 620+ comments.
My incidents were in local dev — rebuildable. His was production. Same root problem: AI agents don't have a permission boundary that matches the blast radius of their actions.
What I built: Aegis
I built Aegis (the divine shield from Greek mythology) — a command firewall that intercepts dangerous commands before they execute and routes them to a web dashboard for human approval.
AI Agent (Claude Code / Hermes / Codex)
↓
PreToolUse Hook intercepts
↓
AST rule engine evaluates risk
↓
block → rejected immediately
review → approval popup in dashboard
warn → logged, passed through
allow → passed through silently
Aegis sits between the model's decision and the actual execution. Not after. Before.
The rule system: your stack, your rules
Aegis ships with 11 built-in rule sets covering common risks. But the rules that will actually save you are the ones you write yourself.
Every developer's stack is different:
- I use Prisma + NestJS + Docker
- You use Django + PostgreSQL + K8s
- Someone else uses Rust + SQLite + custom deploy scripts
No universal rule set can know where your specific mines are buried.
Here's the Prisma rule that would have saved me:
# ~/.aegis/rules/my-prisma.yaml
name: "my-prisma"
version: "2.0"
rules:
- id: my/prisma-migrate-reset
description: "migrate reset --force wipes all data"
example: "npx prisma migrate reset --force"
category: "database"
severity: "error"
action: "review"
reason: "This will delete all data and re-apply migrations from scratch"
selector:
binary: npx
arguments:
- pattern: "prisma.*migrate.*reset"
flags:
anyOf: [force]
- id: my/prisma-db-push-force
description: "db push --force overwrites schema without migration"
example: "npx prisma db push --force"
category: "database"
severity: "error"
action: "review"
reason: "Force push can cause data loss if schema changes are destructive"
selector:
binary: npx
arguments:
- pattern: "prisma.*db.*push"
flags:
anyOf: [force]
aegis rules reload # takes effect instantly, no restart needed
aegis rules list # see all active rules with their source
aegis rules new my-rules # scaffold a new rule file
Your rules have the highest priority. Same id overrides any built-in rule.
The approval dashboard
Real-time interception
When a review-level command fires, a popup appears at http://localhost:3001. The browser at http://localhost:3001 will also send you a notification.
You see:
- The exact command the agent wants to run
- Which rule triggered it and why
- The working directory and agent context
- One-click allow or deny
Auto-deny on timeout
If you don't respond within 60 seconds, it auto-denies. The agent gets an error and stops. This is intentional — if you step away, no command should silently execute while you're gone.
Configurable in ~/.aegis/config.json:
{ "approvalTimeoutSeconds": 60 }
Why not just use a plugin per agent?
| Approach | Coverage | Maintenance |
|---|---|---|
| Claude Code plugin | Claude Code only | Low |
| Hermes skill | Hermes only | Low |
| Aegis PreToolUse hook | All supported agents | One codebase |
One aegis start. Claude Code, Hermes, Code — all covered.
How my workflow changed
-
aegis start— runs in background - Open Claude Code (or Hermes), work normally
- Agent tries to run
prisma migrate reset --force - Aegis intercepts, dashboard popup appears
- I glance at it: "Oh, this time I actually need the reset — allow" or "Wait, that would nuke my test data — deny"
- Agent continues or gets an error and explains why
I no longer rely on the agent "remembering" anything. Dangerous operations must pass through me.
Current state and roadmap
Works today:
- Claude Code, Hermes (PreToolUse hook integration)
- macOS and Linux
- 11 built-in rule sets, 100+ rules
- Custom YAML rules with hot reload
- Project-level rules (
.aegis/rules/in your repo) - Web dashboard with real-time event stream
Planned:
- Codex CLI, OpenCode support
- Windows support
- Full session audit log (complete timeline of what the agent did, what Aegis caught, what you approved)
- Code diff snapshots before agent edits — one-click rollback without polluting git history
On the diff snapshots: I don't want to git commit every tiny AI change. I don't want a history full of "fix by AI" × 20. I want a buffer between agent edits and clean commits.
Has this happened to you?
I'm curious — has your AI agent ever done something you didn't expect? A command that wiped data, modified files you didn't want touched, or pushed something you weren't ready for?
And more broadly: what's your biggest pain point when working with AI agents on real projects?
I'm still shaping Aegis's roadmap and would love to hear what actually hurts. Drop it in the comments — every response genuinely helps.
MIT licensed. github.com/yezannnnn/aiAegis
npm i -g ai-aegis && aegis setup && aegis start
Top comments (0)