DEV Community: Zayd Mulani

My "secure" sandbox detected an attack and reported success anyway. Here's the marshaling bug that caused it.

Zayd Mulani — Mon, 24 Aug 2026 21:36:24 +0000

I built a tool (mri) that runs untrusted code snippets inside a sandbox, checked against an execution allowlist derived from a dependency graph. Before I trusted it for anything, I wrote a demo: three attacks, all blocked. Then I stopped testing.

That was a mistake, and I only found out because I went back and wrote a second benchmark whose entire purpose was to disprove the first one — 19 cases of ordinary code that should just run, and 14 attack cases that weren't in my original three.

The legitimate-code suite failed first, and badly. 5 of 19 normal patterns got blocked, including a plain function declaration with parameters and a try/catch block. The static scanner registered local bindings for arrow-function params but never for function_declaration params or catch-clause bindings — so those names looked like unresolved external references to the scanner, and unresolved means blocked, by design. A tool that blocks ordinary code isn't safer than one that doesn't. It's the kind of tool that gets a comment added to disable it.

The attack suite found something worse than a missed attack. One case: a getter that doesn't touch process.env until the return value gets read on the way out of the sandbox. That access triggered the runtime's real violation check — the detection fired correctly. Then the code responsible for serializing that return value back to the host caught the resulting error, converted it to a string, and handed back a clean "executed" result. Nothing in the breach log. The check worked and the report lied about it. I'd rather have a tool that misses something and says so than one that catches something and hides it.

Also found: the sandbox wasn't a real boundary in the first place. I was using node:vm, and console.log.constructor.constructor (or the same trick through any host-provided reference) reaches the host process's actual Function constructor. This is documented — Node's own docs say vm doesn't provide security isolation — but "documented" and "tested against my own code" are different things, and I hadn't done the second one.

Fixed the sandbox by moving to isolated-vm, a real separate V8 isolate rather than a shared-realm context. Fixed the marshaling bug by making sure any violation, wherever it's triggered from, produces a blocked verdict before a return value ever gets serialized. Re-ran the full 33-case benchmark after both fixes: zero regressions, both cases now correctly blocked.

Still true after the fixes: no OS-level sandboxing underneath the isolate, no taint tracking between two resources that are each individually granted, and it only evaluates one snippet at a time — no whole-program analysis.

Repo, including the benchmark harness and raw per-case results: https://github.com/zaydmulani09/mri

I built a static + runtime security scanner for MCP servers (Rust)

Zayd Mulani — Wed, 19 Aug 2026 04:05:33 +0000

I built a static + runtime security scanner for MCP servers (Rust)

TL;DR: MCP (Model Context Protocol) has had 40+ CVEs disclosed just this year, and there wasn't a purpose-built scanner for it, so I built one. sentrymcp does static analysis (path traversal, injection, tool poisoning, missing auth) plus a runtime proxy mode that catches "rug pulls" — servers that silently change a tool's description after you've already approved it. Rust, MIT, Docker one-liner. Repo: https://github.com/zaydmulani09/sentrymcp

Why this exists

I've been building MCP tooling for a while (a reverse proxy, some agent infra), and at some point I went looking for something to check my own servers for basic security mistakes before shipping them. There wasn't really anything.

That surprised me, because the CVE numbers aren't small. Endor Labs analyzed over 2,600 real MCP implementations and found 82% use file operations prone to path traversal, 67% use APIs related to code injection, and 34% use APIs susceptible to command injection. Separately, researchers have put the no-auth rate at around 38-40% of scanned servers — meaning close to 2 in 5 MCP servers in the wild have no authentication at all.

The vulnerability classes aren't exotic either. Anthropic's own reference implementation, mcp-server-git, shipped a path traversal bug where a repo_path argument was never validated against a configured boundary — the exact "developer forgot one check" pattern that shows up constantly in these audits.

So: static analysis for the code-level stuff, and since MCP has an attack class that literally can't exist in source code (a server that changes its tool description mid-session, after the user already approved the original), a runtime mode to catch that too.

What it catches

Category	What it detects	Example
Code vulnerabilities	Path traversal, command/shell injection, unsafe eval/code-injection sinks	Unvalidated file path args, string-interpolated `exec()` calls
Tool poisoning	Hidden instructions embedded in tool descriptions, unicode/homoglyph obfuscation	"ignore previous instructions" phrasing, Cyrillic lookalike characters hiding in description text
Auth & permissions	Missing auth on HTTP/SSE transports, hardcoded credentials, credentials leaked via logging	`api_key = "sk-..."` as a literal, unauthenticated SSE endpoints
Runtime (proxy mode)	Tool description changes after initial approval ("rug pulls"), unexpected outbound connections	A tool's description silently changes between the first and second `tools/list` call in a session

The tool-poisoning detection is the one I'm most interested in feedback on. MCP tool descriptions get read directly into the model's context as trusted content, so an attacker who controls a description can hide instructions the LLM will act on while the user only sees a benign-looking label. sentrymcp checks for imperative hidden-instruction phrasing, zero-width/bidi-control unicode, and homoglyph mixing (Latin text with Cyrillic or Greek lookalike characters slipped in).

Usage

Static scan:

mcpaudit scan ./some-mcp-server

Output is ranked by severity with a CWE or OWASP MCP Top 10 reference and a one-line remediation for each finding, split into three sections — code vulnerabilities, tool poisoning, and auth/permissions.

Runtime proxy mode, sitting between your MCP client and the real server:

sentrymcp proxy -- <your-server-command>

This baselines every tool definition it sees on session start and diffs every later tools/list response against it. Any change gets flagged and logged as a JSON event, with a human-readable summary at session end.

Docker, no local Rust toolchain needed:

docker build -t sentrymcp .
docker run --rm -v $(pwd):/scan sentrymcp scan /scan

How it's built

Rust workspace, four crates: a core scan engine, a rules crate that loads detection patterns from TOML files (so adding a new check doesn't require recompiling), a CLI, and the proxy. Rule-driven design was a deliberate choice — path traversal, injection, and tool-poisoning heuristics are all just declarative pattern definitions with a severity, a reference (CWE or OWASP MCP Top 10 id), and remediation text, which makes the ruleset easy to extend as new attack patterns show up.

Limitations (being upfront about these)

Detection is regex/pattern-based, not AST or taint-tracking. It'll miss vulnerabilities that flow through an intermediate variable before hitting a sink — this is a known, documented gap, and proper taint analysis is the natural next step.
Description extraction for tool-poisoning checks is targeted, not a full parser — it handles the common registration patterns in Python/TS/JS but isn't exhaustive.
The runtime proxy's network-connection monitoring is currently Windows-only and best-effort (polls netstat, not a real sandbox).
Heuristic findings (like "no visible auth pattern anywhere in the file") are marked with a confidence flag separate from severity, since absence-of-pattern checks are inherently noisier than presence-based ones.

Try it / feedback wanted

Repo's here: https://github.com/zaydmulani09/sentrymcp — MIT licensed, contributions welcome. If you run MCP servers, I'd genuinely appreciate people trying the scanner against their own and telling me what it misses or false-positives on. The corpus of test cases is still small and real-world feedback is the fastest way to make the ruleset actually useful instead of just theoretically correct.

I built a local LLM that runs entirely in your browser. No install, no GPU, no server

Zayd Mulani — Mon, 27 Jul 2026 18:34:05 +0000

A few months ago I got obsessed with a question: can you run a real LLM entirely inside a browser tab, with zero backend, zero GPU, and zero install?

The answer is yes. Here's what I built.

ghost is a single HTML file that downloads a quantized language model into your browser's cache on first visit, then runs inference locally in WebAssembly forever after. Fully offline after that first download. No API key. No npm. No build step. Open the file, pick a model, chat.

How it works

The inference engine is wllama — a WebAssembly binding for llama.cpp. It runs GGUF quantized models directly in the browser using WASM SIMD. I pin it to a specific version so the JS and WASM files always match (learned this the hard way after a fun debugging session involving mismatched memory imports).

Models are downloaded from HuggingFace on first load and cached via the browser's Cache API. On every subsequent visit they load instantly from cache, no network needed.

Features

Three models: Qwen2.5 1.5B (smart), Qwen2 0.5B (fast), TinyLlama (lightweight)
Markdown rendering from scratch — no library, just regex transforms
RAG: drag a .txt or .pdf onto the chat window. It chunks the text, embeds each chunk using wllama's embedding API, stores vectors in memory, and retrieves the top-3 relevant chunks on each message. Fully local, fully offline
Voice input via the Web Speech API — mic button auto-sends on silence
Multi-turn conversation memory capped at 10 turns
PWA installable — works on mobile home screen too

The hard parts

Getting wllama to load from a cached model was genuinely tricky. Blob URLs created in the main thread aren't accessible from wllama's internal Web Worker. IndexedDB chunk reconstruction hit a 2GB ArrayBuffer limit on Windows Chrome. The final solution was using wllama's built-in loadModelFromHF with useCache: true which handles everything internally.

The embeddings API requires toggling a flag (embeddings: true) that conflicts with normal chat completion — so I toggle it on before each embedding call and back off in a finally block.

Try it

Live: https://zaydmulani09.github.io/ghost/ghost.html
GitHub: https://github.com/zaydmulani09/ghost

Speed on CPU is ~3-8 tokens/sec depending on model. Not fast, but it works, and every token stays on your machine.

I built a local-first coverage-guided fuzzer in Rust with LLM seed bootstrap

Zayd Mulani — Tue, 14 Jul 2026 13:27:34 +0000

I built a local-first coverage-guided fuzzer in Rust with LLM seed bootstrap

rust #opensource #security #fuzzing

The problem that kept bothering me: I wanted to fuzz a custom binary protocol parser. Not something with a public corpus of real traffic. Just a service my team built that speaks a length-prefixed binary format over TCP.

AFL++ requires a C harness. cargo-fuzz wraps libFuzzer but you still need to write the harness and you're starting from random bytes. Neither tool helps you when the first thing the parser does is check a 4-byte magic header and exit if it doesn't match. You spend hours getting past that check before you find anything real.

So I built Phaedra.

The LLM seeding idea

The core insight is that you don't need random bytes to start. You need bytes that look plausible. If you describe what your target parses in plain English, a language model can generate a structured initial corpus.

phaedra fuzz \
  --target ./my_parser \
  --description "TLV binary protocol with PHDR magic header, u8 type, u16be length, payload bytes"

Phaedra sends that description to a local Ollama instance and gets back hex-encoded seed inputs. No API key, no data leaving your machine. OpenAI and Anthropic work as drop-in backends if you want them.

The seed generation prompt asks for variety: valid inputs, boundary values, truncated records, inputs where the length field exceeds the payload. The parser gets past the magic check immediately because the seeds include valid magic bytes. Campaign starts finding new coverage on the first execution instead of the hundredth.

Coverage via SanCov edge bitmaps

Once you have seeds, you need coverage feedback. I chose SanCov edge bitmaps over shared memory rather than LLVM .profraw files for one reason: speed. Reading a profraw file after each execution means a file write, a file read, and a parse. Shared memory is a single shmat call and a memcpy.

The setup: Phaedra allocates a 65536-slot edge bitmap in POSIX shared memory, passes the segment ID to the target via __PHAEDRA_SHM_ID, and the target's SanCov runtime shim writes edge hit counts directly into that segment on every execution. After the process exits, Phaedra reads the bitmap, XORs against the global "seen" bitmap, and if new edges fired, the input goes into the corpus.

The shim is a small C file that gets compiled into the target:

void __sanitizer_cov_trace_pc_guard(uint32_t *guard) {
    if (!*guard || !phaedra_map) return;
    phaedra_map[(*guard - 1) % PHAEDRA_MAP_SIZE]++;
}

Schema-aware mutation

Random byte mutation gets past the magic check once you have good seeds. But it still struggles with structured fields. If your protocol has a u16be length prefix followed by exactly that many payload bytes, random mutation almost never produces a valid record because it corrupts the length without adjusting the payload.

The schema DSL solves this. You describe your protocol in TOML:

name = "my_protocol"

[[fields]]
name = "magic"
type = "magic"
length = 4
value = "50484452"
mutable = false

[[fields]]
name = "length"
type = "u16_be"

[[fields]]
name = "payload"
type = "lp_bytes16_be"

30% of mutations operate at the field level: corrupting the length prefix specifically, setting it to 0, to max value, or to a value larger than the actual payload. The other 70% are still raw byte mutations. The split keeps the campaign from getting stuck in schema-valid inputs only.

If you have a corpus but no schema, phaedra infer analyzes the samples with six heuristics and writes a starting schema:

phaedra infer --corpus-db ./phaedra-corpus/corpus.db --name my_proto

Crash triage

When Phaedra finds a crash it deduplicates by signal number and input fingerprint. SIGSEGV and SIGABRT are CRITICAL. SIGILL and SIGFPE are HIGH. No-signal crashes are LOW. Each unique signature gets one entry in SQLite with a hit counter so if the same bug triggers 500 times you see one entry with hit_count=500, not 500 files in your crash directory.

phaedra crashes

ID  SEVERITY   HITS  SIGNATURE     STATUS
1   LOW        47    crash_3f2a1b  Crash { signal: None }
2   LOW        12    crash_7e4d2c  Crash { signal: None }

phaedra minimize runs delta minimization to reduce a crashing input to the smallest bytes that still trigger it. Found a 200-byte crash? It will usually get it down to under 10.

Try it

cargo install phaedra
phaedra fuzz --demo tlv

The TLV demo target has a real bounds-check bug. Phaedra finds it within the first few seconds.

GitHub: https://github.com/zaydmulani09/phaedra

I built a local token cost tracker for Claude Code in Rust

Zayd Mulani — Mon, 13 Jul 2026 21:58:53 +0000

After one too many surprise Claude Code bills, I built agentwatch.
It's a local HTTP proxy written in Rust. Point your agent at localhost:7878, and it intercepts every request, parses the token usage, and shows a live Ratatui TUI dashboard of what you're spending — in real time.
Everything stays local. SQLite database, zero signup, single binary via cargo install agentwatch.
Supports Claude Code, Codex, and Gemini CLI.
github.com/zaydmulani09/agentwatch

I built a self-hosted reverse proxy for MCP servers in Rust

Zayd Mulani — Thu, 02 Jul 2026 18:52:40 +0000

The problem

Every AI tool that talks to MCP servers (Claude, Cursor, etc.)
connects directly — no auth, no rate limiting, no observability.
You have no idea what's hitting your servers or how often.

What I built

MCP Gateway sits in front of all your MCP servers and handles:

Routing — /mcp/server-name/* proxies to the right backend
Auth — per-server API keys encrypted AES-256-GCM in memory
Rate limiting — token bucket per client, 429 + Retry-After
Logging — SQLite log of every request with latency + status
Usage tracking — token counts from Anthropic/OpenAI responses
CLI — mcpgw server add/list/remove, mcpgw logs show, mcpgw stats

Quickstart

MCPGW_MASTER_SECRET=your-secret docker compose up --build

Stack

Rust, Axum, SQLite (rusqlite), DashMap, AES-GCM

GitHub: https://github.com/zaydmulani09/mcp-gateway

I built a local-first AI memory layer for LLMs in Rust (no cloud, no API keys)

Zayd Mulani — Wed, 03 Jun 2026 20:33:22 +0000

Every LLM app has the same problem — the model forgets everything between
conversations. Cloud solutions like Mem0 exist but they send your data
to their servers. I built mnemo to solve this locally.

What it does

mnemo runs as a sidecar process next to your app. You POST text to it,
it extracts named entities and relationships using a local LLM (Ollama),
builds a persistent knowledge graph, and injects relevant context back
into your prompts automatically.

The stack

Rust — core engine, 4 crates (mnemo-core, mnemo-api, mnemo-cli, mnemo-bench)
SQLite + WAL mode — persistent storage, survives restarts
petgraph — in-memory knowledge graph with BFS traversal
Axum — REST API sidecar any app can call
Ollama — fully local LLM, zero API costs

Fully free by default

docker compose up -d
docker exec mnemo-ollama ollama pull llama3
curl http://localhost:8080/health

Works with OpenAI or Anthropic too if you bring your own key.

Python SDK

from mnemo import MnemoClient

client = MnemoClient()
client.ingest("I'm building a Rust vector database called vecdb")
print(client.get_context("what am I working on?"))

Numbers

122 Rust tests, 21 Python SDK tests
Sub-millisecond entity lookup
~4ms full retrieval pipeline (debug build)

Links

GitHub: https://github.com/zaydmulani09/mnemo

Would love feedback, especially on the retrieval scoring and graph
traversal approach.

I built an open-source dependency intelligence platform in TypeScript — here's how it works

Zayd Mulani — Fri, 29 May 2026 12:13:27 +0000

Most teams find out their dependencies are risky after something breaks. A maintainer disappears, a vulnerability sits unpatched for months, or a single package with one contributor becomes a hidden outage waiting to happen. I wanted a tool that told you this stuff before it became a problem.
So I built depgraph — an open-source dependency intelligence platform that crawls npm, PyPI, and Cargo registries, builds a live risk-scored dependency graph, and tells you exactly which packages in your supply chain are about to cause you pain.
What it does
Risk scoring across 6 dimensions
Every package gets scored on security (open advisories, CVSS scores), maintenance (commit recency, release cadence), compatibility (semver violation rate), concentration (bus factor, single-maintainer risk), blast radius (how many downstream packages break if this one changes), and operational health (issue response latency, PR merge time).
These combine into a single composite score with full explanations — not just a number, but "35% because maintainer activity fell 80% in 120 days."
Interactive dependency graph
Built with Cytoscape.js. Click any package to see its full transitive dependency tree, blast radius stats, and which packages it would take down if it disappeared. Chokepoint detection highlights the packages that are structurally too central to ignore.
Policy engine with CI gate
Define rules like "block packages with one maintainer and no release in 180 days" or "require approval for anything with 500+ downstream dependents." A GitHub Action runs the policy check on every PR and fails the build on violations — with a formatted comment showing exactly what triggered and how to fix it.
Abandonment detection
Time-series signals track commit frequency trends, maintainer count decay, and bus factor over time. A weighted model produces an abandonment probability score per package so you can see which ones are quietly dying before they become your problem.
Historical snapshot diffs
Every scan creates a full risk snapshot. Compare any two snapshots to see which packages degraded, which improved, what new vulnerability chains appeared, and how your overall supply chain health changed over time.
Tech stack
TypeScript monorepo with pnpm workspaces. Hono API, React + Vite frontend, PostgreSQL + Drizzle ORM, BullMQ workers, MinIO for raw storage. Fully self-hostable — one docker compose up and you're running. Zero paid services required.
Supports npm, PyPI, and Cargo with a shared normalization layer that maps all three ecosystems to a canonical data model.
Running it locally
bashgit clone https://github.com/zaydmulani09/depgraph
cd depgraph
pnpm install --ignore-scripts
cp .env.example .env
docker compose up -d
pnpm db:migrate
pnpm --filter @depgraph/api dev &
pnpm --filter @depgraph/crawler dev &
pnpm --filter @depgraph/ui dev
Open localhost:5173. The crawler seeds 10 packages immediately and starts processing — within a few minutes you'll see risk scores, graphs, and explanations populating in the UI.
What I learned building this
The hardest part wasn't the risk scoring or the UI — it was maintaining a living graph. Getting data once is easy. Keeping it fresh, detecting drift, diffing snapshots, and making all of that fast enough to be useful is where the real complexity lives.
The second hardest part was normalization. npm, PyPI, and Cargo all have wildly different versioning semantics, dependency specifier formats, and registry API shapes. Building a canonical model that works cleanly across all three took longer than any other single component.

Check it out, open issues, and PRs are welcome.
GitHub: https://github.com/zaydmulani09/depgraph

I built a local-first hybrid vector database in Rust from scratch

Zayd Mulani — Tue, 19 May 2026 01:29:22 +0000

A few months ago I started building vecdb — a vector database that
runs entirely on your own machine. No cloud, no API keys, no subscription.

The problem

Most vector databases make you choose — semantic search OR keyword search.
Semantic search finds meaning but misses exact keywords. Keyword search
finds exact matches but misses meaning.

vecdb combines both in a two-stage pipeline:

HNSW dense index retrieves candidates by meaning
BM25 sparse index re-scores by keyword relevance
A fusion function combines both scores

What it can do

Hybrid HNSW + BM25 retrieval
SQL-like query language with VECTOR_SIM predicate
Python and TypeScript SDKs
Single binary, Docker support
187 tests
MIT license

Example query

SELECT * FROM documents
WHERE VECTOR_SIM(vec, [0.1, 0.2, 0.3]) > 0.75
AND payload->>'region' = 'US'
LIMIT 10;

Try it

GitHub: https://github.com/zaydmulani09/vecdb

Would love feedback from the community — especially on the
architecture and what to tackle in v0.2.0.