AI coding agents read files and follow instructions with tool access. That
means a repo is not just code anymore. It is an instruction environment: a
README, an HTML comment, an MCP config, a postinstall script, or a Claude
Code hook can steer an agent the moment it enters. The HTML-comment attack is
documented in the wild.
azt scans a repo before Claude Code, Cursor, Codex, or Gemini operates in it.
It inventories everything that can influence an agent (14+ file classes,
including .mcp.json, hooks, .envrc, folderOpen tasks, lifecycle scripts) and
flags known injection, execution, and exfiltration shapes.
Three design choices I expect HN to have opinions about:
1. The core is deterministic and offline. No model calls, ever. There is a
bootstrap paradox in LLM-based screening: content being judged can inject the
judge. A scanner vulnerable to the attack it screens is worse than nothing,
because it manufactures false confidence.
2. It publishes its own false-negative ledger. corpus/misses/ contains working
attacks the scanner does NOT catch, asserted undetected in CI so the ledger
cannot silently drift. A clean scan means "no known-shape red flags", never
"safe".
3. It disclosed its own day-one bypass. The first version's gate could be
forged by an agent's file-write tool. Found it in our first live test, fixed
it the same day, disclosed in SECURITY.md.
Try it in 30 seconds, no install (stdlib only):
git clone https://github.com/ralfyishere/agent-zero-trust
cd agent-zero-trust
python3 azt.py scan corpus/malicious-markdown # exits 1, red findings
Or: pipx install agent-zero-trust && azt scan <repo>. There is also a GitHub
Action and a gate mode that blocks an agent's tools until an intake scan
passes (a speed bump, not a sandbox).
It's not a replacement for Snyk's agent-scan, which inventories your installed
agent/MCP/skill components. azt is the other side: intake for a repo you're
about to enter. Run both.
Single file, stdlib only, MIT. Bypass reports are the most wanted
contribution: every confirmed one becomes a rule or a public entry in the
misses ledger, credited.
ralfyishere•1h ago
azt scans a repo before Claude Code, Cursor, Codex, or Gemini operates in it. It inventories everything that can influence an agent (14+ file classes, including .mcp.json, hooks, .envrc, folderOpen tasks, lifecycle scripts) and flags known injection, execution, and exfiltration shapes.
Three design choices I expect HN to have opinions about:
1. The core is deterministic and offline. No model calls, ever. There is a bootstrap paradox in LLM-based screening: content being judged can inject the judge. A scanner vulnerable to the attack it screens is worse than nothing, because it manufactures false confidence.
2. It publishes its own false-negative ledger. corpus/misses/ contains working attacks the scanner does NOT catch, asserted undetected in CI so the ledger cannot silently drift. A clean scan means "no known-shape red flags", never "safe".
3. It disclosed its own day-one bypass. The first version's gate could be forged by an agent's file-write tool. Found it in our first live test, fixed it the same day, disclosed in SECURITY.md.
Try it in 30 seconds, no install (stdlib only): git clone https://github.com/ralfyishere/agent-zero-trust cd agent-zero-trust python3 azt.py scan corpus/malicious-markdown # exits 1, red findings
Or: pipx install agent-zero-trust && azt scan <repo>. There is also a GitHub Action and a gate mode that blocks an agent's tools until an intake scan passes (a speed bump, not a sandbox).
It's not a replacement for Snyk's agent-scan, which inventories your installed agent/MCP/skill components. azt is the other side: intake for a repo you're about to enter. Run both.
Single file, stdlib only, MIT. Bypass reports are the most wanted contribution: every confirmed one becomes a rule or a public entry in the misses ledger, credited.