MakerChecker puts a policy gate in front of AI agents that can delete, trade or exfiltrate

Why it matters

Agent security is shifting from prompt filters to enforceable permissions, audit trails and human approval gates around tool calls.

MakerChecker is pushing a security model for AI agents that starts with a blunt premise: the dangerous part of an agent is the tool it is allowed to call, so the control point belongs before execution.

The public repo is active as of July 6, 2026 and still small by open-source adoption signals. At scrape time, MakerChecker showed 59 commits on main, 68 branches, 10 tags, 0 forks, and 3 stars. That is not evidence of adoption. It is evidence of a project being assembled in public.

The maintainers are not identified in the repo or the available project pages. There is no disclosed founder name, funding round, customer list, revenue claim or company entity. That absence matters because MakerChecker is making a trust claim in a category where trust is the product. For now, the verifiable story is the code, the docs and the control model: a new open-source attempt to make agentic systems auditable before operators wire them into finance, health care, software deployment and other workflows where a mistaken tool call can move from inconvenience to liability.

What MakerChecker actually scans

The scanner is designed to run locally with:

npx @makerchecker/scan .

MakerChecker says the scan requires no install and that "nothing leaves your machine." The scanner looks for capabilities such as deleting data, moving money, running shell commands and exfiltrating secrets. The README says it classifies findings by risk, maps them to real incidents and can write governance code with a --fix flag.

That framing shifts control away from the model and onto the tool path. The model can still hallucinate or be compromised, but its call to a consequential tool has to pass through an external policy layer.

The repo is not just a scanner. It includes an embedded enforcement package, SDKs, connectors for frameworks including LangChain and the Claude SDK, a self-hosted Fastify and Postgres server, a React console, a proof verifier, examples, docs, a Helm deployment path, an injection-gauntlet directory and a spec path for agent-action-proof. A July 3 commit message says MakerChecker added runnable reproductions for 41 incidents, which gives the project a concrete corpus around agent-tool risk rather than a generic checklist.

The control model is separation of duties

MakerChecker's README puts the enforcement layer in front of each tool call and behind it as a signed ledger. The configuration model is role-based: define skills, define roles, grant skills to roles, define agents and deny ungranted calls before they execute.

The examples show permissions attached to roles rather than agents; if a role has not granted a skill, the wrapped tool call is denied. That borrows a well-known enterprise separation-of-duties pattern and applies it to AI agents. The agent can prepare the work. A separate role must approve the risky action. Every allow or deny decision is written into an audit log.

The project describes a cryptographically signed, hash-chained log for decisions and tool calls, plus a verifier so exported proofs can be checked offline. More details are on the MakerChecker homepage.

That approach should resonate with regulated buyers, if the implementation holds. Compliance teams already understand maker-checker controls in finance, pharma and enterprise software release processes. MakerChecker is trying to make that pattern native to AI agent runs rather than bolted on afterward.

The first markets are obvious

The examples in the repo point at regulated workflows where an agent can assemble or triage work, but a human gate blocks the final irreversible action.

The timing is also clear. AI agents are moving from demos into workflows that touch credentials, files, SaaS systems, code repositories and payment rails. If an agent cannot act, it is a chatbot. If it can act, someone has to answer who gave it that authority, what limit applied and whether the same actor prepared and approved the outcome.

A May arXiv technical report examined public agent skills and found confirmed malicious payloads and critical security issues. MakerChecker is one answer to the same market pressure: operators need to know what agent-connected code can do before it runs, and they need controls that survive a bad prompt.

A crowded category is forming fast

MakerChecker is entering a security subcategory that is filling quickly. Mondoo announced AI Skills Check on April 21, 2026, describing it as a free, agent-agnostic scanner for identifying hidden risks in AI agent skills across registries before deployment. Mondoo says its checker compares what a skill claims to do against code and behavior, and supports environments including Claude Code, Cursor, Windsurf, custom Anthropic SDK agents and MCP servers.

Mitiga launched Skillgate on June 16, 2026, saying it scans AI-agent skills and configurations across popular tools and formats.

Guard0 positions g0 as an open-source scanner that maps agents, tools, prompts, MCP servers and related security domains, with CI gating and SARIF-style output. AgentVerus offers skill-risk scans, trust scores and cryptographic attestations. Evoke Security announced a $4 million pre-seed round in February, led by Crosspoint Capital Partners with participation from Red Cell Partners, for visibility and control over enterprise AI agents. Cisco said in May that it intended to acquire Astrix Security, tying the deal to discovery and security for AI agents and non-human identities.

The crowded field helps MakerChecker more than it hurts at this stage. The existence of scanners, skill registries, MCP gateways, non-human identity tools and agent governance startups shows buyers are beginning to budget for this problem. MakerChecker's narrower wedge is the two-key rule: scan the code, define the role, block the call, record the proof.

The hardening path will matter

MakerChecker's default quickstart is built for evaluation, not a production security guarantee. Barista Labs published a June 17 teardown that praised the separation-of-duties model but noted a sharp implementation concern: the quickstart runs as the Postgres owner, which can disable append-only triggers unless the hardened setup is used. That does not negate the model. It does mean security buyers should judge MakerChecker by its hardened deployment path, proof verifier and operational controls, rather than by the fastest demo path.

Licensing also follows an open-source split. The repo indicates an AGPL-3.0 core with Apache-2.0 SDKs.

The unanswered question is distribution. A security layer for agents needs more than a persuasive README. It needs framework integrations that stay current, CI workflows developers will tolerate, false-positive rates low enough for engineering teams, and deployment guidance that compliance and security teams can defend under audit. MakerChecker has the right shape of product for the problem. The next proof will be whether builders of real agents treat policy-gated tool calls as a default control rather than an optional wrapper they add after the pilot succeeds.

RuntimeWire has been tracking the same pattern in other open-source AI infrastructure projects, from Okhai's Foundation stack to recent solo-builder systems work around Phargo and NanoEuler. MakerChecker belongs to that wave, but its stakes are different. If AI agents are going to be allowed to touch money, customer data, medical workflows and production systems, the founder or maintainer who wins this layer will be selling a simple promise: the agent can do useful work without becoming the only person in the approval chain.