DEV Community: Ilias Almerekov

I built Aegis — a firewall between AI coding agents and your shell

Ilias Almerekov — Thu, 09 Jul 2026 07:58:19 +0000

A few months ago I watched Claude Code run rm -rf on a directory it had misunderstood. Nothing critical was lost, but it got me thinking: I had given an autonomous agent unrestricted access to my shell, and the only thing standing between it and my filesystem was... nothing.

So I built Aegis — a small Rust CLI that sits between an AI agent and your real shell, and checks every command before it runs.

The problem

AI coding agents are genuinely useful, but they move fast and they make mistakes. The failure modes are well known by now:

deleting files or whole directories they misidentified
resetting or force-pushing git history
dropping database tables
publishing packages you didn't mean to publish

Most agents have their own permission prompts, but those live inside the agent. One misconfigured "auto-approve" setting, one YOLO mode session, and there's nothing left between the model and your data.

What Aegis does

Aegis intercepts every command and classifies it into one of four risk levels:

Level	What happens
Safe	Runs immediately — no delay, no prompt
Warn	Pauses and asks for your approval
Danger	Takes a best-effort snapshot first, then asks
Block	Refused outright — no prompt

ls, cargo build, git status — these run instantly. The classification happens in under 2 milliseconds, so on the happy path you never notice Aegis is there.

But when the agent tries something like rm -rf ~/.config, you get this instead of silent data loss:

⚠ DANGER — FS-001 · Recursive delete
Command rm -rf ~/.config
Risk Danger
Pattern FS-001 — rm with -rf flag
Snapshot git stash created (a3f9b12)

[A] approve [D] deny [i] info

Note the snapshot line: before a dangerous command even asks for approval, Aegis takes a best-effort snapshot (git stash, or a Docker/SQLite-aware backup depending on context). If you approve the command and regret it, you can roll back. If you deny it, the snapshot is retained anyway.

Everything — every command, every decision, every snapshot — goes into an append-only, integrity-checked audit log. You can always answer the question "what exactly did the agent do yesterday?"

How it hooks in

For Claude Code and Codex, Aegis registers PreToolUse hooks, so every Bash command the agent runs goes through the scanner regardless of what $SHELL is set to:

aegis install-hooks --all

For other agents that respect $SHELL, there's a shell-proxy mode:

aegis setup-shell

This points SHELL at the aegis binary and keeps your real shell in AEGIS_REAL_SHELL. Aegis parses the command, classifies it, and only forwards to your real shell what you approved.

The interesting engineering bits

The hot path is Aho-Corasick, not regex. The first pass over every command is a multi-pattern scan with zero allocations. Regex only kicks in for commands that trip the fast scan. That's how safe commands stay under 2 ms.

Shell parsing is where the real work is. Agents don't write polite one-liners. They write heredocs, inline scripts, pipes, bash -c inside bash -c, and quoting that would make POSIX blush. Aegis has its own parser for this, and it's fuzzed in CI — because a guardrail with a parser bypass is worse than no guardrail at all. Some of the bypasses we've already fixed: uppercase variations, $IFS obfuscation, SQL hidden inside psql/mysql invocations.

Hooks fail closed. If the aegis binary goes missing or a hook dependency breaks, the hook denies the command instead of silently letting it through. A safety tool that fails open is just decoration.

Config can only get stricter. A per-project .aegis.toml can tighten the security posture but never weaken it. So a repository you cloned (or an agent editing files in it) can't quietly turn the guardrails off.

What Aegis is not

I want to be honest here, because security tools that oversell themselves are a plague: Aegis is a heuristic guardrail, not a sandbox. It is not a privilege boundary. A determined attacker — or a sufficiently creative agent — can construct commands that evade pattern-based classification. There's a full threat model (https://github.com/IliasAlmerekov/aegis/blob/main/docs/threat-model.md) in the repo that spells out exactly what's in and out of scope.

What Aegis protects you from is the realistic everyday case: an agent making an honest mistake at machine speed. In my experience, that covers the vast majority of near-disasters.

Try it

curl -fsSL https://raw.githubusercontent.com/IliasAlmerekov/aegis/main/scripts/install.sh | sh

Or via npm / Homebrew if you prefer your installs package-managed:

npm i -g @iliasalmerekov/aegis

or

brew tap IliasAlmerekov/aegis && brew install aegis

Then verify it's working:

aegis -c 'echo hello'              # safe — runs instantly
aegis -c 'rm -rf /tmp/aegis-test'  # danger — prompt appears, press D

Linux, macOS, and WSL2 are supported (no native Windows build).
GitHub (https://github.com/IliasAlmerekov/aegis) — issues and PRs welcome, especially bypass reports. If you can sneak a dangerous command past the scanner, I genuinely want to know.

Reviving My School's AI Assistant: Moodle + Ollama

Ilias Almerekov — Thu, 28 May 2026 07:54:01 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Moodle AI Assistant — an AI-powered learning companion embedded directly into Moodle, the LMS used at my vocational school Berufsschule ITECH in Germany, where I'm training as a Fachinformatiker (IT Specialist)

This project means a lot to me because it solves a real problem I see every day at school: students get stuck on assignments after hours, teachers get flooded with the same repeated questions, and there's no smart help available on demand. I built this to change that.

Demo

Github Repository: https://github.com/IliasAlmerekov/moodle
Demo Video: https://youtube.com/shorts/Iiy4re43cMM?feature=share

The Comeback Story

The project started as a school initiative at Berufsschule ITECH. My teachers loved the idea and we were planning to finish it together and actually deploy it to the school's real Moodle instance. Then our block-based curriculum kicked in — a new Lernfeld (learning field) began, everyone's schedules shifted, and the project quietly slipped into the "we'll get back to it someday" pile.

It sat there. Months passed. Then I found the GitHub Finish-Up-A-Thon Challenge — and something clicked. This was exactly the push I needed. The thought of finally showing my teachers a working, production-ready version of what we once planned together was all the motivation I needed to open the repo again.

My Experience with GitHub Copilot

When I first built this project, I had a GitHub Student subscription with access to powerful models and no strict weekly limits. Back then, Copilot was my real pair programmer — it helped me move fast and learn even faster.

Unfortunately, the tighter weekly limits that came later made it much harder to use Copilot the same way. But those months of working with it weren't wasted — I learned a lot, grew as a developer, and now I feel ready to come back to this project and do a full refactoring, applying everything I picked up along the way.

The Comeback 04.06.2026: What was broken and What I Actually Fixed?

The prototype worked — it answered questions. But it was a single-file Fastify server with logic mixed into routes, and it would not have survived contact with real students. Here's the honest before → after, by area:

🔐 Identity

Before: userId trusted straight from the request body — any user could read another's chat (IDOR).
After: HMAC-SHA256 signed identity, constant-time verify, per-session ownership checks (401/403).

🏛️ Architecture

Before: Business logic tangled into route handlers.
After: Clean Architecture, 4 layers, dependency rule enforced — use cases testable without Fastify or Docker.

🤖 AI grounding

Before: The model could see all courses.
After: Course search is fail-closed to the student's own enrolments; no secrets reachable by the model.

🛡️ Frontend XSS

Before: Model output dumped into raw innerHTML.
After: DOMPurify + tag/attribute allowlist + Moodle-origin-locked links, with a CSP backstop.

⚙️ Reliability

Before: Direct fetch, no limits.
After: Timeout + retry (Moodle), circuit breaker + bounded queue (Ollama), graceful shutdown, SSE abort on disconnect.

💾 Persistence

Before: In-memory — every restart wiped all chat history.
After: SQLite (WAL, prepared statements, indexed, retention pruning) behind a repository interface.

🚀 Deploy

Before: Manual, container ran as root.
After: Multi-stage non-root Docker image, healthchecks, ordered startup, one-command Compose.

✅ Quality gate

Before: None.
After: 417 tests, ESLint, Prettier, npm audit, Gitleaks, Trivy image scan + container smoke test in CI.

The 3 critical blockers I closed for this challenge

Unauthenticated PII leak — /moodle/user/:id and /moodle/users/:id/courses returned personal data with no auth (only accidentally hidden by nginx routing). Now production-gated to 404.
Known high-severity CVEs — Fastify 4.28.1 carried 3 high CVEs (body-validation bypass, host/proto spoof). Upgraded to Fastify 5 + matching plugins; npm audit now reports 0 vulnerabilities.
Root container, no build hardening — rebuilt as a multi-stage image running as USER node with npm ci and a HEALTHCHECK.

Where I was honest instead of perfect

I didn't fake "done." The per-user rate limiter is in-memory (fine for a single instance, documented as a known limit), and the prompt-injection guard is a best-effort blocklist — its real safety net is that the model simply can't reach anything sensitive (fail-closed course scope, no secrets in context). These are written down in the README's Limitations section, not hidden.

The result

The prototype went from "it answers questions on my laptop" to a production-lite service: Clean Architecture (90/100 in my own readiness
review), HMAC auth, sanitized LLM output, resilient external calls, persistent history, a hardened container, and a full CI pipeline — all
behind a single docker compose up.

The next step is the one that started it all: showing my teachers a working version, and finally deploying it to the school's real Moodle
instance.

Thank You 🙏

Huge thanks to GitHub and the DEV community for the chance to take part in such a cool challenge. The Finish-Up-A-Thon was exactly the push I needed to reopen a project I genuinely cared about and finally carry it across the finish line.

These challenges do more than hand out prompts — they turn "someday" projects into shipped ones and give motivation real momentum. Thank you for creating that space. I had a great time building this, and I'll happily jump into more challenges like this one in the future. 🚀