Tool

Enforce human approval gates and audit trails for AI agents

MakerChecker is an open-source security layer that gives AI agents deny-by-default permissions, human approval gates, and a signed audit trail.

Works with langchainclaudecrewaipostgresdocker

91
Spark score
out of 100
Updated 6 days ago
Version 1.2.0
Models
claude

Add to Favorites

Why it matters

Prevent AI agents from executing high-risk actions without human authorization by wrapping tool calls in deny-by-default governance, routing sensitive operations to separate approval roles, and maintaining a cryptographically signed, tamper-evident audit log that proves no agent can approve its own work.

Outcomes

What it gets done

01

Scan codebases to identify and classify risky agent capabilities by severity tier

02

Block unauthorized tool calls before execution using role-based skill grants

03

Route high-risk actions to human reviewers who cannot be the requesting agent

04

Generate verifiable audit trails with Ed25519 signatures and hash-chained event logs

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/makerchecker-makerchecker | bash

Overview

MakerChecker

MakerChecker is an open-source security layer for AI agents that enforces deny-by-default tool permissions, routes high-risk actions to a separate human-approval role so an agent can't approve its own work, and writes every decision to a hash-chained, Ed25519-signed audit trail. Use it when an AI agent takes consequential actions (money, data deletion, shell commands, regulatory filings) and you need enforced permissions plus an independently verifiable audit trail; it wraps your existing agent framework rather than replacing it.

What it does

MakerChecker is an open-source security layer for AI agents that sits in front of every tool call as a checkpoint and behind it as a signed ledger. Agents keep running in their existing framework (LangChain, Claude SDK, CrewAI); MakerChecker adds deny-by-default enforcement so an agent acts only through a role, runs only the skills it was explicitly granted, cannot exceed its limits, and - critically - cannot approve its own work, since high-risk skills are assigned to a separate role.

The project ships as three independent packages that enforce the same controls and write the same signed audit format, adoptable individually: mc scan (run via npx @makerchecker/scan .) analyzes existing agent code with nothing leaving the machine, flags every consequential action (deleting data, moving money, running shell commands, exfiltrating secrets), names each against the real-world incident it resembles, and can generate governance code automatically with --fix. @makerchecker/embedded provides importable enforcement primitives: you define skills, roles, and grants, then wrap a tool with governedTool() so any call the agent's role wasn't granted is denied before it executes, throwing a GovernanceDeniedError with a code like skill_not_granted. The self-hosted server (docker compose up) adds centralized enforcement across many agents, a human-approval inbox, and a review console backed by Postgres.

Every decision and tool call - allowed or denied - commits to a hash-chained audit log: each event is a SHA-256 hash over the RFC 8785 canonical JSON of the event, chained through prev_hash from genesis and Ed25519-signed. Changing any row breaks verification, and an exported bundle can be verified offline with no database and no trust required in the process that produced it, via npx @makerchecker/proof-verifier verify bundle.json.

When to use - and when NOT to

Use MakerChecker when your AI agent takes consequential actions - moving money, deleting data, running shell commands, submitting regulatory filings, approving transactions - and you need a structural guarantee that ungranted actions are denied before execution and that high-risk actions require a human who is not the agent's own requester to sign off, with a tamper-evident, independently verifiable audit trail for auditors or regulators. The documented example flows (pharmacovigilance case processing, medical-device complaint triage, oncology patient access, daily cash reconciliation) are all regulated, high-consequence domains where a self-approval loophole would be a real incident, not a theoretical risk.

It is not a replacement for the agent framework itself - it's a governance layer that wraps tools inside LangChain, the Claude Agent SDK, CrewAI, or custom code, so you still need the underlying agent. Adopting only mc scan gives you visibility and risk classification without runtime enforcement; centralized cross-agent enforcement, the approval inbox, and the review console specifically require running the self-hosted server component.

Inputs and outputs

Input at the scan stage is your existing agent codebase, analyzed locally with npx @makerchecker/scan . (no install, nothing leaves the machine); output is a risk-classified report of consequential actions the agent can already take, optionally paired with --fix to generate governance code. At the embedded stage, input is a governance definition (skills with risk tiers, roles, grants, and agents) plus the tool function to wrap:

import { createGovernor, GovernanceDeniedError } from "@makerchecker/embedded";

const gov = createGovernor()
  .defineSkill("place-order@1", { riskTier: "high" })
  .defineRole("agent")
  .defineRole("risk-desk")
  .grant("risk-desk", "place-order@1")
  .defineAgent("trader", "agent");

const placeOrder = gov.governedTool("trader", "place-order@1", (order) => broker.submit(order));

Output is either the tool's normal result or a thrown GovernanceDeniedError carrying a machine-readable code (e.g. skill_not_granted), plus a signed audit-log entry for every decision, allowed or denied. Running the self-hosted server outputs an admin API key (for agent runs) and an officer API key (for human approval decisions) via docker compose up, exposing REST endpoints for starting flow runs, listing pending approvals, submitting approval decisions, and verifying the audit log (/api/audit/verify).

Integrations

MakerChecker provides drop-in connectors for LangChain and the Claude Agent SDK, plus TypeScript and Python SDKs (@makerchecker/sdk, the Python sdk-python package) exposing a governedTool / governed_tool helper that routes each call through a proxy session on the server for centralized authorization and recording. The self-hosted server runs on Fastify and Postgres, ships a React console (packages/web) for the approvals inbox, run log, and skill registry, and supports Kubernetes/Helm deployment. Audit bundles are independently verifiable offline with the separate @makerchecker/proof-verifier package, with no dependency on the database that produced them.

Who it's for

Teams putting AI agents in front of consequential, regulated, or high-risk actions - financial transactions, regulatory filings, healthcare workflows, infrastructure changes - who need a structural, auditable guarantee that agents can't exceed their granted permissions or approve their own work, and who want that enforcement to work with whatever agent framework (LangChain, Claude Agent SDK, custom code) they already use rather than requiring a rewrite. It is licensed under AGPL-3.0 (core) / Apache-2.0 (SDK, connectors, scan).

Source README

๐Ÿ›ก๏ธ MakerChecker

The open-source security layer for AI agents.

Deny-by-default enforcement, human approvals, and a cryptographically signed audit trail - so your agent runs only what it's granted and provably can't approve its own work.

CI
Release
License
Stars

Website ยท Live Demo ยท mc scan ยท Docs

Your agents keep running in their existing framework (LangChain, Claude SDK, CrewAI). MakerChecker sits in front of every tool call as a checkpoint and behind it as a signed ledger: an agent acts only through a role, runs only the skills it was granted, cannot exceed its limits, and cannot approve its own work.


๐Ÿš€ Quick Start

1 - Scan your code

Find what your agent can already do on its own, classified by risk. No install, nothing leaves your machine:

npx @makerchecker/scan .

It flags every consequential action - deleting data, moving money, running shell commands, exfiltrating secrets - names each against the real incident it resembles, and can write the governance code for you with --fix. โ†’ packages/scan

2 - Guarantee its behavior

Import the controls and wrap any tool. The agent can now only run what its role was granted - a call it isn't allowed is denied before it executes:

npm i @makerchecker/embedded
import { createGovernor, GovernanceDeniedError } from "@makerchecker/embedded";

const gov = createGovernor()
  .defineSkill("place-order@1", { riskTier: "high" })
  .defineRole("agent")
  .defineRole("risk-desk")
  .grant("risk-desk", "place-order@1")   // the agent is NOT granted it โ€” deny by default
  .defineAgent("trader", "agent");

// Wrap your tool once. Now the agent structurally can't fire it.
const placeOrder = gov.governedTool("trader", "place-order@1", (order) => broker.submit(order));

try {
  await placeOrder({ symbol: "BTC", qty: 10 });
} catch (err) {
  if (err instanceof GovernanceDeniedError) console.log(err.code); // "skill_not_granted"
}

High-risk skills go to a separate role, so an agent can never approve its own work - and every decision, allowed or denied, commits to a signed audit log. โ†’ packages/embedded

3 - Working with auditors?

Step 2 already writes a signed log. When auditors need a durable, queryable, tamper-evident record - plus a human-approval inbox and a review console - run the self-hosted server:

docker compose up

Every decision is Ed25519-signed and hash-chained: change any row and verification breaks. Export a bundle and anyone verifies it offline - no database, no trust in the process that produced it. โ†’ full server setup below

These are three independent packages - mc scan, @makerchecker/embedded, and the server - that enforce the same controls and write the same signed audit format. Adopt any one on its own.


๐Ÿ”ฌ Governed Use Cases

Runnable examples of agents doing consequential work behind a human gate:

  • Pharmacovigilance case processing - an agent triages adverse-event reports, but a medical reviewer signs before an expedited 15-day regulatory report transmits. examples/pv-icsr-processing
  • Medical-device (MDR) complaint triage - a regulatory officer decides reportability behind a gate before draft reports are generated. examples/mdr-reportability-triage
  • Oncology patient access - an agent handles benefit matching but is blocked from submitting copay enrollments without a specialist signing. examples/oncology-patient-access
  • Daily cash reconciliation - a finance agent reconciles transactions but locks at exception gates until a cash officer signs off. examples/daily-cash-reconciliation

๐Ÿ”Œ Integrate With Your Framework

Drop-in connectors govern the tools you already have:

When you run the server, the SDK's governedTool routes each call through a proxy session for centralized authorization and recording:

import { createClient, governedTool, GovernanceDeniedError } from "@makerchecker/sdk";

const client = createClient({ baseUrl: "http://localhost:3000", apiKey: "mk_..." });
const { session } = await client.proxy.openSession({ label: "recon-run" });

const match = governedTool(
  client, session.id,
  "recon-preparer",   // agent whose role grants are evaluated
  "txn-match@1",       // skillRef: name@version
  (input) => matchTxns(input),
);

await match({ statement, ledger });   // throws GovernanceDeniedError if denied
await client.proxy.closeSession(session.id);

๐Ÿ–ฅ๏ธ Self-Hosted Server (optional)

Run the full gateway when you need centralized enforcement across many agents, a human-approval inbox, and a review console. docker compose up brings up Postgres, the server on localhost:3000, and a seeded demo, printing two API keys - an admin key (your agent authenticates runs) and an officer key (a human reviewer approves gated actions).

The seeded pharmacovigilance flow parks at a medical-review gate where the requester is refused as its own approver:

export H='authorization: Bearer mk_...'         # admin key
export OFFICER='authorization: Bearer mk_...'   # officer key

curl -X POST localhost:3000/api/flows/pv-icsr-processing/runs -H "$H" -H 'content-type: application/json' -d '{}'
curl localhost:3000/api/approvals -H "$H"

# The requester cannot approve their own run โ€” rejected with 403
curl -X POST localhost:3000/api/approvals/<id>/decision -H "$H" -H 'content-type: application/json' \
  -d '{"decision":"approved","reason":"self-approval attempt"}'

# A separate officer signs; only now does the action proceed
curl -X POST localhost:3000/api/approvals/<id>/decision -H "$OFFICER" -H 'content-type: application/json' \
  -d '{"decision":"approved","reason":"Seriousness confirmed; file 15-day expedited ICSRs."}'

curl localhost:3000/api/audit/verify -H "$H"

Full setup, Kubernetes/Helm, and running with live models: docs/quickstart.md.


๐Ÿ”’ Verifiable Audit Trail

Every decision and tool call commits to a hash-chained log - each event a SHA-256 over the RFC 8785 canonical JSON of the event, chained through prev_hash from genesis and Ed25519-signed. Change any row and verification breaks. Anyone can verify an exported bundle offline - no database, and no trust in the process that produced it:

npx @makerchecker/proof-verifier verify bundle.json

Spec: docs/audit-spec.md.


๐Ÿ—‚๏ธ Packages

Package License What it is
packages/scan Apache-2.0 mc scan - finds and classifies what your agent can do.
packages/embedded Apache-2.0 Importable enforcement primitives - governance in your code.
packages/proof-verifier Apache-2.0 Independently verify a signed audit bundle offline.
packages/sdk Apache-2.0 TypeScript client + governedTool for the server.
packages/sdk-python Apache-2.0 Python client + governed_tool.
packages/connector-langchain Apache-2.0 Govern LangChain tools.
packages/connector-claude-agent Apache-2.0 Govern Claude Agent SDK tools.
packages/server AGPL-3.0 Self-hosted Fastify + Postgres gateway, flow engine, audit writer.
packages/web AGPL-3.0 React console: approvals inbox, run log, registry.
packages/shared AGPL-3.0 Domain types, canonical JSON, crypto utilities.

๐Ÿ“„ License & Contributing

  • Server, Web, Shared: AGPL-3.0.
  • mc scan, embedded, SDKs, connectors, examples: Apache-2.0 - embed them in closed-source agents freely.
  • Commercial (non-copyleft) licensing: hello@makerchecker.ai.

Contributing: CONTRIBUTING.md ยท Security: SECURITY.md ยท Code of Conduct: CODE_OF_CONDUCT.md

FAQ

Common questions

Discussion

Questions & comments ยท 0

Sign In Sign in to leave a comment.