Vigil is a deterministic rule engine that inspects AI agent tool calls before they execute. 22 rules across 8 threat categories: destructive shell commands, SSRF, path traversal, SQL injection, data exfiltration, prompt injection, encoded payloads, and credential exposure. It's not an LLM wrapper — we don't trust an LLM to guard another LLM. Pure pattern matching, zero dependencies, <2ms per check, works completely offline.
npm install vigil-agent-safety
import { checkAction } from 'vigil-agent-safety'; const result = checkAction({ agent: 'my-agent', tool: 'exec', params: { command: 'rm -rf /' }, }); // result.decision → "BLOCK" // result.reason → "Destructive command pattern" // result.latencyMs → 0.3
It plugs into MCP servers, LangChain tool chains, Express middleware, or anything else. MIT licensed, no API keys, no network calls, no telemetry.
This is v0.1 — probably too aggressive for some use cases. Next up is a YAML policy engine (v0.2) and an MCP proxy. We'd love feedback on the rule set, false positive experiences, and threat categories we're missing.
HexitLabs•2h ago
Some context on why we built this: you might have seen the post earlier this week about someone building a file recovery tool after Claude Code rm -rf'd their Obsidian vault through a symlink. We had similar near-misses running our own agent swarm, agents curling cloud metadata endpoints, attempting path traversal, executing destructive commands during "cleanup" steps. We kept adding one-off guards and eventually realized this should be a proper library.
The main design choice was making it deterministic rather than using an LLM to review tool calls. An LLM guarding another LLM felt like asking the fox to guard the henhouse. Pattern matching is boring, but it's fast, predictable, and works offline.
Happy to hear about false positives, missing threat categories, or use cases where the rule set is too aggressive. That's the main thing we want to calibrate for v0.2.