An open source governance scanner that flags AI agents for dangerous tool calls and uses an LLM to auto generate the wrappers around them. The recursion is the design choice.
MakerChecker's --fix flag asks an LLM to write the guardrails that police other LLMs. The scanner flags tool calls that delete data, move money, run shell, or exfiltrate secrets; --fix then auto-generates the wrappers that would let those calls proceed under guardrails. The wrapper-author is an LLM. The thing being wrapped is an LLM. That recursion is the design choice.
The project was posted to Show HN on July 6, 2026. It ships in two pieces. [scan](https://github.com/makerchecker/MakerChecker/blob/main/packages/scan/README.md) is a static analyzer that runs against a codebase. [embedded](https://github.com/makerchecker/MakerChecker/blob/main/packages/embedded/README.md) is a runtime library that sits in front of every tool call: agents act only through a defined role, run only the skills they've been granted, and cannot approve their own work. When a call crosses a line, the gateway raises GovernanceDeniedError. Every approved action is recorded in a cryptographically signed audit trail. The agent frameworks underneath, LangChain, Claude SDK, CrewAI, stay as they are. MakerChecker attaches to them.
The threat model the project assumes is the honest one. Modern agents can execute shell commands, hit payment APIs, and read production data. Where MakerChecker gets subtle is in the auto-fix loop. A flagged call like place-order@1, marked as a high-risk skill, doesn't only get denied. With --fix, the project's own README instructs the scanner to draft the wrapper code that would let the call proceed under guardrails. The maintainer trusts the scanner's authoring model to write correct governance for code the scanner just flagged as dangerous. That is a single point of trust failure applied twice.
The first hours of the HN thread pushed a different counter: much of this could be enforced with OS-level user permissions and process isolation. Run the agent as a low-privilege user, fence the filesystem, strip dangerous binaries, sandbox shell. No LLM in the loop, no signed ledger, no framework interop layer. For many small deployments, the kernel is already a more trustworthy enforcement boundary than a wrapper library the agent can read.
The lane MakerChecker sits in is already familiar: limits, approvals, and audit trails stacked on top of agent frameworks as bolt-on governance. It is distinct from model-level safety work like Constitutional AI or RLHF, which tries to make the model itself refuse dangerous calls. MakerChecker's bet is that the model cannot be trusted to refuse and that the enforcement layer must be external. The recursive trust problem does not contradict that bet; it sharpens it. External enforcement is the right goal. Handing the enforcement code to an LLM narrows the gap on syntax and widens it on semantics.
How --fix lands in the next few weeks will tell readers where the project stands. If the maintainers add a required human review step before each generated wrapper is committed, the recursive trust problem narrows to a paper tiger. If --fix stays a one-shot suggestion, the audit trail records a governance decision made by the same kind of model the audit trail is supposed to constrain. That question, who audits the auditor, already runs through the codebase.