How it works
MakerChecker is a self-hosted checkpoint that sits outside the model, in code, at the execution boundary. Skills are deny-by-default, and segregation of duties is enforced in code: the agent that proposes an irreversible action is refused as its own approver, a hard 403. Reversible work clears on its own. The irreversible call waits for a second, named human, and every decision commits to a signed log your auditor verifies offline, with no access to your systems. That is the engine on this page.
What makes it different
Locked permissions, a sign-off, a tamper-evident log: any engineer can wire these up. The hard part is who vouches for what happened. The team that built the system cannot be the one who proves it. So we built the record to be one your auditor checks for themselves, without relying on whoever built or runs the agent.
The party that builds or runs the agent cannot be the one who proves the record is real. We keep the proof outside the agent, the way a SOC 2 only counts when the auditor has no stake. It holds up to someone looking for a reason to doubt it, not just a dashboard.
We build and run the agent, and we run it where you already work, on LangChain, CrewAI, the Claude Agent SDK, or your own code, inside your own walls. The action and its record are written together, so an agent that acted but left no trace simply cannot happen.
Hand over a signed file and your auditor re-checks it on their own laptop, in any language, with no access to our systems and no code from us. Change one line and the file stops checking out. The deal is check it yourself, not take our word.
The core is genuinely open. The engine is AGPL-3.0, the SDK is Apache-2.0, you run it yourself, and you can air-gap it. The team that signs off on the integration reads every line first, before anything touches a real action. Below is the engine those three claims rest on, the six things it enforces.
The engine, in six parts
Before an agent takes a high-consequence action, it is held to the separation any serious operation puts on people: a defined role, deny-by-default access, a required second sign-off on the irreversible step, and a log that breaks if any line is changed. This is domain-neutral, the same whether the action moves money or changes a patient record. These six hold whether or not anyone remembers a procedure, and each one writes its own proof as the action runs.
An AI agent is modeled the way a regulated company models a person: it is an identity that holds exactly one role at a time. The role is the unit of authority. Nothing an agent does is anonymous, and nothing it can do is implicit, capability flows only through the role it wears.
Maps toAttributability, the ALCOA “Attributable” principle.
A role is a key ring. Each grant opens one specific door, a tool, a connector, a skill, and everything not granted is denied. Grants are versioned, so you can reconstruct exactly what any agent was permitted to do on any past date. This is the difference between a control and a fence: a tool list hard-coded by the developers who built the agent has no record of who approved it, no history, and no revocation trail.
Maps toAccess limited to what is explicitly granted; authority checks (e.g. 21 CFR §11.10(d)/(g)).
If an agent prepared the work, it is impossible, not discouraged, impossible, for that agent’s role to approve it. The separation is enforced structurally inside the run, at runtime, by construction. The attempt is refused and the refusal lands in the log. No tracker, content filter, or scoped credential can express “may prepare or approve, but never both on the same item.”
Maps toMaker-checker; quality-unit independence (e.g. 21 CFR §211.22).
A gate is a step in the workflow, not a notification bolted on afterward. It demands a quorum, n of m named approvers, and the human who requested the action can never be one of them. When a person signs, their reason is captured verbatim and bound to the decision, so the signature carries its meaning.
Maps toSignature with recorded meaning (e.g. 21 CFR §11.50).
A role carries the limits of its authority: a monetary threshold above which a human must sign, a cap on how many times a skill may fire, a budget on tokens. Limits are set and owned by the compliance side, not the developers who build the agent, and when a limit is reached, the system fails closed.
Maps toDelegated-authority limits.
Every action, every model call, every approval lands in a sealed, append-only chain. Change one record and the chain breaks at that record. You can export a signed evidence bundle that an outside inspector verifies offline, with no access to your systems or ours, against a published, open formula anyone can reimplement. The record stands on its own math, not on our word.
Maps toAudit trails and signature linking (e.g. 21 CFR §11.10(e), §11.70).
Why this and not a control plane
Teams already limit their agents. They hard-code which tools an agent can call, and IT scopes its credentials. Control planes go further, giving each agent an identity and watching the whole fleet. All of it is real and useful, and we sit alongside it. Those tools run the fleet inside your own walls, and they keep a log you own.
That is enough for a dashboard. It is not enough the day an auditor asks who decided. Your staff carry keycards too, and your own auditor still expects delegation logs, signature authority, and a second set of eyes on top, because locking the door does not prove who walked through. The engine above is that missing piece. What makes it ours is the one thing a team cannot add to its own system: the agent cannot vouch for its own work, so the record is one your auditor recomputes for themselves, offline, with no access to your systems. A control plane runs the fleet. We are the file your auditor checks.
Keep reading
See it for yourself
One command starts the demo: an agent stopped from signing off its own work, and the signed evidence file an inspector can check for themselves.
Designed against the rules your auditors already enforce.