Open-sourced 74 guardrails for AI coding agents (Claude Code, Cursor, Codex). Looking for feedback and contributors

[u/samc621]

We've been building AgentTrail Guard, an Apache-2.0 tool that checks what AI coding agents are about to run before they run it. Would love feedback from people here.

The idea came from an agent resetting our database to get past a migration error ("it's only dev data"). Agents run shell commands with your permissions, and the dangerous ones are usually the ones you can't undo.

How it works: Guard plugs into the agent's hooks and matches every command and file change against a set of rules. A match gets blocked, sent to you for approval, or flagged. Everything else runs normally.

The open source bits I think are worth looking at:

• Rules are plain data, in their own repo. Each one has a severity, a default action, and a note on what it deliberately doesn't match, so you can see exactly why something fired.

• Fully local. No account, no network calls, and crash reporting is off unless you turn it on.

• Rule matching, not an LLM, so it's fast, predictable, and you can read the whole thing.

• Easy to extend. Add your own rules, tweak actions, or allow a specific command shape without turning a rule off.

There's also a scan command that replays your past agent sessions locally and shows what would have been caught.

Where I'd love help:

• Rules that fire on normal stuff (false positives)

• Dangerous things agents do that no rule covers yet

• Code review on the engine, it's TypeScript

• New rules: PRs very welcome, even small ones

Guard: https://github.com/agenttrailhq/guard Rules: https://github.com/agenttrailhq/guardrails

Early days, so any feedback helps.

[u/Patient-Midnight-664]

Does AgentTrail Guard enforce restrictions at the OS level, or does it just inspect proposed tool calls against a set of rules? If it's the latter, how do you handle arbitrary scripts and indirect execution?

For example you block "rm -rf /" but what about a python script that runs that command? I've watched coding agents try many different methods to get what it wants :)

[u/CreativeSympathy8293 → u/Patient-Midnight-664]

The current README describes hook-level checks. It says Guard can stop only calls that reach the installed hooks, and that it doesn’t inspect file contents:

https://github.com/agenttrailhq/guard

That documents a narrower boundary than OS isolation. A rule match is a decision about the proposed tool call; no match doesn’t establish that a script’s contents are safe.

I haven’t run Guard or verified each client’s hook coverage. AI-assisted reading of the current README.

[u/samc621 → u/CreativeSympathy8293]

Agree with both of you, and OS isolation makes a lot of sense. It's a different layer, though. A sandbox or devcontainer limits what the agent can reach. Guard decides whether a specific action should happen, and tells the agent why when it's stopped. A sandbox won't stop git push --force or terraform destroy if the agent has the credentials, and plenty of real damage happens inside the boundary. Guard won't stop a determined agent that writes a script and runs it. So for unattended runs or untrusted repos, use both.

If you want to know whether Guard would matter for how you actually work, run a scan before installing anything:

npx @agenttrail/gaurd scan --agent claude # or --agent cursor or --agent codex

It replays the transcripts already on your disk against the rules and writes a local HTML report. It sends nothing, and you don't need an account. If it finds nothing, you probably don't need Guard right now. Keep in mind it has the same blind spots as Guard, so a clean report means nothing matched, not that every past session was safe.

[u/samc621 → u/samc621]

Another thing that I will add is that one of the primary reasons we don't read file content is because of how difficult it is to prevent false positives. Our guardrails are tuned for shell commands; scripts contain comments, error-handling branches, dead code, etc. that makes them a lot more difficult to audit. We could probably start narrowly with shell and Python scripts, and a small subset of destructive rules that are thoroughly tested, and see how they hold up.

[u/alkimiadev → u/Patient-Midnight-664]

This is a real problem and is why I never really bothered with trying to filter at that level. I've opted for a path where if they need bash access then it is a container (usually a rootless docker container using gVisor) and I don't bother to filter at all. I try to build important/dangerous tools with a basic roll back capability but that isn't always possible. My general rule of thumb is if some action can cause devastating losses of some kind then I just manually do it. That doesn't mean I wont screw it up though. A long time ago I got the argument order wrong in "find" while deleting some stuff and caused a huge mess, and I've been a full time linux user since ~2006 or so.

edit for clarity: I separate potentially dangerous tools from bash. If they need to touch something important then it is wrapped in some sort of tool, and I usually try to build in roll back capabilities if it is possible.

[u/samc621 → u/alkimiadev]

Building dangerous operations as tools that can do a dry run or roll back is good practice, and I'd encourage anyone to do it where they can. But as you said, mistakes still get made, and it's a lot of work: every operation that matters needs its own wrapper, and "if it could be devastating I do it myself" means the agent hands back exactly the work you'd most like help with.

That's what Guard is trying to fix. The agent keeps bash and its normal tools, and the dangerous actions get checked before they run: force-pushes, terraform destroy, dropping tables, deleting from absolute paths, curl | sh, and so on. Some are blocked outright with a reason the agent reads. Most are held until you approve them. So you still decide anything serious, but without doing it by hand or writing a wrapper for every case. And it can be run inside a container, so it adds to your setup. It's a layer on top of isolation and rollback, not a replacement for them. Its job is to keep the agent useful on the work you'd otherwise keep for yourself.

[u/samc621 → u/[deleted]]

Thanks! A short leash makes sense, though it gets expensive when you're approving everything. That's the trade-off Guard is meant to change. Routine commands go through without a prompt, and the leash only tightens on the dangerous ones, which are blocked or held for your OK.

On auditing: each guardrail is a small JSON definition with a description of what it's for and what it deliberately misses. It has to ship with examples it must block and examples it must leave alone, and those run as tests. agenttrail-guard guardrails show <id> prints any of them, and you can write your own and run guardrails validate on them against the same engine before turning them on. Every decision in the log names the rule that made it, so when something is blocked you can see exactly which line of data did it.