The guardrail conversation is mostly about stopping an agent before it acts. These four launches take the other side: assume it acted, then check. One keeps its own record of what happened, one reads your project for the vulnerabilities agents introduce, one judges each tool call locally, and one has an agent write the inputs your tests should have survived. All four are early, all four are open source, and none of them asks you to trust the thing being checked.
An independent record, not the agent's account
Rashomon keeps its own record of what your Claude Code agent actually did — every tool call, subagent and failed command — and puts it beside the summary the agent gives you. The line that matters is at the end of a turn: if the agent says all tests pass and something failed, the record says so. The full report also lists what subagents did, which the main conversation does not show at all, so a subagent that quietly broke something is visible rather than invisible.
The premise is worth stating plainly, because it is the reason this category exists at all: a summary produced by the thing being audited is not an audit. An agent has no reason to lie, but it has every reason to be wrong in the direction of a tidy ending. Rashomon is local-only with no telemetry, Claude Code only, on macOS and Linux, and at alpha v1.1.0. The scope is narrow and the version number is honest about it.
A scanner that reads the AI parts too
Rowan is a static security scanner for AI applications. It reads source code and model files and reports likely vulnerabilities — injection, unsafe deserialisation, SSRF, leaked secrets, risky agent tools, unsafe model loading — with the evidence behind each finding, and it never runs your code. It is MIT licensed, at alpha, and installs with pipx or uv.
What distinguishes it from a generic SAST tool is the scope. Model files and agent or MCP configuration are scanned alongside the source, which is exactly where the new risk lives: a tool definition that is too permissive, a model loaded from an untrusted path, an agent configuration that grants shell access nobody audited. The README is unusually honest that a finding is a lead to check and that a clean report does not prove a project is secure. Expect false positives and read the evidence rather than the severity label.
Every tool call, judged on your machine
Laya guard is a free local guardrail for coding agents. Each tool call is judged on-device before it runs, using regex plus a local model, and the verdict is three-way: allow, send for review, or block. It ships as a PyPI package with a dashboard so you can see what was stopped and why, supports Claude Code among others, and runs on macOS and Linux.
The three-way verdict is the design decision worth copying. A binary allow-or-deny guardrail pushes everything ambiguous into either a flood of false blocks or a silent pass; a review state gives the ambiguous middle somewhere to go. At 33 stars it has the most traction of anything in this batch. The costs are real: latency on every call, and a judgement that is only as good as the rules and local model behind it.
An agent that attacks your own tests
LLM Fuzz CI is a GitHub Action with a neat inversion. A coding agent reads your code and writes adversarial inputs for the tests you mark, then your normal test run replays them, and the action reports only the inputs that actually fail. So every report is a real failure of your own assertions rather than a CVE list rated medium that programmers learn to dismiss. It works on Python and JavaScript and is MIT licensed.
The inversion matters because it changes the signal-to-noise ratio. A scanner tells you something might be wrong somewhere in a dependency tree; this tells you your own assertion about your own code is false, and shows you the input that proves it. The limit is stated on the tin: it is only as good as the tests you mark for it, and a project with no assertions gets nothing at all.
The shape of the problem
Notice what none of these do: none of them try to decide whether a prompt is safe. They check outcomes. That is a much easier problem, and it composes — you can run the record, the scanner and the fuzzer on the same commit and get three independent opinions that do not share a failure mode. A guardrail can be bypassed by an input it did not anticipate; a scanner can miss a pattern it does not know; a fuzzer can only find what your tests can express. Run all three and the gaps stop overlapping.
If you are already running a guardrail, these are the tools that tell you whether it was worth running. And if you are not, the cheapest place to start is the record: you cannot tell whether an agent is getting things wrong until you know what it actually did.
