There is a quiet contradiction in most "governance" tools sold to regulated firms. The product exists to prove you are in control of your AI agents — yet to use it, you ship the record of every action, every approval, and every denial to a server the vendor runs. You are now asked to trust a third party with the exact evidence you would one day need to use against a third party. For a bank or a drug manufacturer, that is not governance. It is a new dependency wearing governance's clothes.
The alternative is older and duller and correct: run the governance layer yourself, inside your own environment, where the data was already allowed to be. MakerChecker is built to be self-hosted by default. Your agents, your roles, your approval chains, and your audit trail all live on infrastructure you already operate and your security team already cleared. Nothing has to leave the building for an agent to be governed.
"Self-hosted" is not a deployment preference
In an unregulated startup, where the software runs is a matter of convenience. In a regulated firm it is a matter of law and liability, and the two are not the same conversation.
Consider what the audit trail of an AI agent actually contains. In an anti-money-laundering workflow it holds account identifiers, transaction patterns, and the reasoning behind a decision to file — or not file — a suspicious-activity report. In a pharmacovigilance workflow it holds adverse-event details and patient-linked case data. That record is not metadata. It is the most sensitive material the firm handles, concentrated in one place, structured for analysis.
Sending that to a vendor's cloud crosses lines the firm spent years defending: data-residency commitments, customer due-diligence confidentiality, the patient-data handling its own GxP procedures require. A governance tool that forces a data-export to function has, on day one, manufactured a compliance problem larger than the one it claims to solve.
Self-hosting removes the question entirely. The data never crosses the boundary because the governance runs inside it.
What "nothing phones home" actually means
Many tools call themselves self-hosted and still maintain a quiet connection to the vendor — license checks, usage telemetry, a "control plane" the customer's instance reports into. Each of those is a channel, and a channel a regulator will ask about. What leaves your network, where does it go, and what is in it? "We only send anonymised telemetry" is the start of an investigation, not the end of one.
MakerChecker is designed to need none of that. It runs with no outbound dependency on the vendor: no phone-home, no license server it must reach to keep working, no telemetry pipeline carrying your operational data out. The system that authorizes your agents does not require permission from anyone outside your walls to do its job.
This is what makes the next property possible.
Air-gapped: governance without a network
An air-gapped system is one with no connection to any external network — the machine, or the whole segment, is physically and logically isolated. It is the standard posture for the most sensitive environments in finance and life sciences: trading-system back ends, manufacturing-execution systems on a GMP production line, classified or export-controlled research.
A great deal of software simply cannot run there, because it assumes a reachable internet — to validate a license, fetch an update, or call its own backend. MakerChecker is designed to operate fully air-gapped. Because it carries no mandatory outbound dependency, it can govern agents inside an isolated segment exactly as it does anywhere else: the same deny-by-default grants, the same structural segregation of duties, the same signed audit export.
That matters because the highest-stakes agentic work tends to live precisely in the environments that cannot reach the internet. If your governance only functions where there is a network connection, it does not function where you most need it to.
The audit evidence is yours, not a feature you rent
The point of the whole exercise is the tamper-evident audit trail — the hash-chained, Ed25519-signed record that lets a third party verify, offline, that an agent did only what it was authorized to do and that the record was not altered. Where that record physically lives changes what it is worth.
When the evidence sits in a vendor's system, you do not hold your own proof. You hold a view of it, granted by the party being examined, retained on the vendor's schedule, exportable on the vendor's terms. If that vendor changes its pricing, suffers an outage, gets acquired, or shuts down, your evidence of a decision your regulator holds you responsible for is now governed by someone else's commercial fortunes.
| Where the evidence lives | Who controls retention | Who can revoke your access |
|---|---|---|
| Vendor cloud | The vendor | The vendor |
| Your own environment | You | No one |
Self-hosted, the audit trail is yours in the literal sense: it is in your Postgres database, on your storage, under your retention policy, subject to your backups and your legal holds. When discovery or a supervisory inspection arrives, you produce the evidence directly. You are not asking a third party for permission to defend yourself.
Open source and Postgres-backed: you can inspect every line
There is a deeper reason self-hosting matters, and it is about trust rather than location. A self-hosted black box is still a black box. You would be running code you cannot read, on data you cannot afford to lose, and taking the vendor's word for what it does.
MakerChecker is open source. The enforcement logic — how a grant is checked, how segregation of duties is applied, how the audit chain is built and signed — is readable by your own security and validation teams. When an examiner asks how a control works, the answer is not a marketing diagram. It is the source. The verification format is published and open, so the people who must trust the evidence can confirm for themselves that the format is honest, rather than taking it on faith.
The state lives in Postgres — a mature, widely understood open-source database your DBAs already run, back up, and audit. There is no proprietary datastore to learn and no opaque format your data is trapped inside. You can query the audit tables directly, apply your existing retention and backup discipline, and keep the records as long as your regulator requires. The governance layer fits the infrastructure you already trust instead of demanding a new one.
Self-hosting is what makes the wrap honest
Running the governance yourself is not a separate idea from the rest of MakerChecker's design — it is the same idea seen from another angle. The product wraps your existing agents rather than migrating them, so the work that already runs keeps running where it runs. Self-hosting is the matching commitment on the governance side: the checkpoint and the witness move to you, instead of you moving to them.
The regulatory backdrop makes the stakes plain. In April 2026 the US banking regulator replaced its model-risk guidance and scoped agentic AI out of it entirely — no supervisory template means no safe harbor, yet examiners and litigation discovery will still demand to know who authorized an action and require a record that has not been altered. The predicate rules underneath, written for people doing these jobs, are date-proof and have not moved. Meeting them means holding your own evidence, in your own environment, in a form you can read and a third party can verify.
A governance tool that asks you to export your most sensitive data to use it has the priorities backwards. The whole job is to keep you in control — and you cannot be in control of what you have handed to someone else.
See how it works, or book a demo to watch an agent get blocked from approving its own work — live, on infrastructure you would run yourself.