DEV Community

Bogumił Jankiewicz
Bogumił Jankiewicz

Posted on

gate.cat: a deterministic, fail-closed veto that stops AI coding agents before rm -rf

AI coding agents now run real shell commands. Most "guardrails" log the damage after the fact. gate.cat vetoes the execution itself — before the shell sees it.

What it does

It blocks irreversible shell commands (rm -rf, DROP TABLE, terraform destroy, secret exfiltration via scp/curl) before they execute. The check is deterministic string + path analysis plus an independent exec analyzer — no model call in the veto path, so a prompt injection can't talk the gate into allowing something. Fail-closed: anything it can't parse becomes a block, never a silent allow.

Three ways to use it

  • Claude Code hook (the strongest — enforcement runs in the harness, outside the model's control flow): pip install gate.cat, then add gatecat-hook to .claude/settings.json with matcher Bash|Write|Edit.
  • Gated shell for any CLI agent (Codex, aider — anything honoring $SHELL): use gatecat-shell.
  • Local proxy for anything speaking the OpenAI API (Ollama, vLLM, LM Studio, OpenRouter): your agent changes one base_url.

Measured, not claimed

Every number below has a row in FACTS.md in the repo, pinned to a reproducible artifact:

  • 1,085,159 unique real agent commands (5 public datasets) replayed through the full 6-stage gate: 0 real misses after adjudication.
  • the reproducible bypass suite catches 178/178 danger shapes it claims — and prints its own known gap (runtime assembly) plus 1 benign false-block in 129 cases. We publish the misses instead of hiding them.
  • 71 default policy walls (73 presets incl. opt-in), ~0.6% intervention rate on real commands.

Honest limit

The gate is certain only about what it blocks. An unmatched action is unchecked, not safe. It's a wall in front of known-dangerous shapes, not a proof of safety — use it with your sandbox, not instead of one.

Free forever, Apache-2.0, zero-dependency core.

What I'd genuinely like feedback on: does publishing our own bypass map and a documented false-block build more trust than a clean number would? That was the hardest design call.

Top comments (5)

Collapse
 
topstar_ai profile image
Luis Cruz

The idea of a deterministic, fail-closed veto like gate.cat is intriguing, especially in the context of AI coding agents that can potentially execute harmful shell commands. I appreciate the detailed explanation of how gate.cat works, including the use of deterministic string and path analysis, as well as an independent exec analyzer. The fact that it has been tested with 1,085,159 unique real agent commands and achieved 0 real misses after adjudication is impressive. I'm also impressed by the transparency in publishing the bypass map and documented false-blocks, which shows a commitment to honesty and building trust with the community. By being open about the limitations and potential gaps in the system, you're allowing users to make informed decisions about how to use gate.cat in conjunction with other safety measures. Does the gate.cat team plan to continue updating and expanding the bypass map and false-block documentation as the system evolves and new potential vulnerabilities are discovered?

Collapse
 
bogumi_jankiewicz_fcfce0 profile image
Bogumił Jankiewicz

Thanks Luis — the transparency point is the one I care about most. The bypass map exists precisely because "trust us, it's safe" isn't good enough for a security tool; you should be able to see exactly where it fails.

One honest caveat I'd stress: the gate is only certain about what it blocks — an unmatched command is unchecked, not proven safe, so it's a complement to a sandbox, not a replacement.

Are you running agents with shell access day-to-day? Curious which entry point fits your setup — the Claude Code hook, the gated shell, or the OpenAI-API proxy.

Collapse
 
komo profile image
Reid Marlow

The fail-closed bit is the important part. I’d still pair this with a disposable workspace or container, because a syntactic veto can only know what it recognizes; the sandbox owns the blast radius. Publishing the bypass map is the right artifact here, not just a green badge.

Collapse
 
bogumi_jankiewicz_fcfce0 profile image
Bogumił Jankiewicz

Exactly right, and it's the framing I want people to take away — the gate is certain only about what it blocks; an unmatched command is unchecked, not proven safe. It's a wall in front of known-dangerous shapes, not a proof of safety, so it belongs next to a sandbox, not instead of one (the sandbox owns the blast radius; the gate tells you what the agent tried). That's exactly why we ship the bypass map and the documented false-block instead of a clean badge. Thanks for reading it closely.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.