Security model
Jailbreaks always succeed. We stop the consequence.
Prompt filters are probabilistic. MakerChecker enforces outside the model, in code, at the execution boundary. A compromised or hallucinating agent can still misuse what it was granted on reversible actions, but it cannot take an irreversible action or approve its own work without a second, named human. It is self-hosted and open source, so your security team reads every line before an agent moves anything that matters.
Deterministic containment
Enforcement sits outside the model, in code, at the execution boundary.
A prompt filter is a probabilistic guess about intent. This is not that. MakerChecker scopes what the agent can physically do and refuses the rest in code, so a jailbreak changes the words the model emits, not the actions the world sees.
- Outside the modelPrompt filters are probabilistic, and a jailbreak that beats the filter beats it silently. MakerChecker does not try to win that race. It enforces in code, at the execution boundary, so the consequence is contained even when the prompt is not.
- Deny-by-default grantsAn agent can invoke only the skills it was explicitly granted, at one pinned version. Everything else is refused before it runs, a hard HTTP 403, not a prompt-level promise.
- Segregation of dutiesThe agent that proposes an irreversible action is refused as its own approver, in code. A second, named human must sign. The identity that did the work is structurally the wrong one to approve it.
- Blast-radius scopingEach grant is scoped to one skill, so a compromised or hallucinating agent can reach only what that skill was given, never the whole surface. The reach of the agent is bounded before a single action runs.
- Reversible vs irreversibleThe honest line: a compromised agent can still misuse what it was granted on reversible actions. What it cannot do is take an irreversible action or approve its own work without a second, named human. We scope the consequence, we do not claim a perfect model.
Self-hosted by design
Your infrastructure, your database, your perimeter.
The thing a security reviewer fears is a vendor service sitting in the data path with your sensitive data and a phone-home channel they cannot see. There is no such service here. It runs where you run, and we never touch your data.
Your perimeter
Runs inside your environment
MakerChecker runs on your infrastructure, inside your network. There is no MakerChecker cloud in the data path, and no tenant of ours sees your data. You operate it the way you operate any internal service.
Your database
Your own Postgres
State and the audit chain live in a Postgres instance you own and manage, under your backup, encryption-at-rest, and access policies. We do not run a database for you and we do not hold a copy.
Air-gapped capable
Runs disconnected
It can run fully disconnected from the internet, the deployment mode validation teams often require. The audit verifier needs no network and no account, so the offline-verify story holds in an air-gapped enclave.
Never phones home
No telemetry out
The service does not call back to us. There is no usage beacon, no remote log shipping, and no hidden dependency on a hosted endpoint. What runs is what you read in the open-source repository.
Database hardening
The audit is only as trustworthy as the store beneath it.
An audit chain on top of a database anyone can quietly edit is theatre. These properties make a direct edit to the store detectable by the same verifier an inspector runs, and make write access to the database insufficient to forge a record.
- Co-commitThe state change and its audit event commit in one database transaction. There is no application path that writes one without the other, so a partial write cannot leave an action unlogged.
- Append-only chainEach audit entry commits the hash of the prior entry. An update or delete at the row level breaks every downstream hash, so direct database tampering is detected by the same verifier an auditor runs.
- Signed chain headThe chain head is signed with an Ed25519 key. Holding write access to the database is not enough to forge a record, because a re-signed forgery fails against the published public key.
- Least privilege by roleDeny-by-default grants mean an agent role can only do what it was explicitly granted, at one pinned skill version. The identity that proposed an action is barred in code from approving it.
Control-to-clause crosswalk
Each control maps to a clause your inspector already enforces.
We never say compliant or validated for you, and we never say certified. We say this: MakerChecker is designed against the requirements of these rules, and it produces the signed artifact each one asks for. The grants and the segregation of duties prevent the wrong action; the chain and the signature prove what happened.
The controls are domain-neutral: deny-by-default grants, segregation of duties in code, and a signed hash chain do not know what industry they run in. The rows below are one worked example, life sciences, where per-case accountability is written down most explicitly. Finance and any other domain with an auditor map the same controls to their own rules. This crosswalk is a map, not a certificate: a clear line from a control your team reads in the code to a clause they have to satisfy.
- 21 CFR Part 1111.10(e) audit trails and 11.50 signature meaning. The signed export carries the approver, the date and time, the signature meaning, and the verbatim reason. We produce the evidence Part 11 asks for; the hash chain goes beyond what it requires and we never claim it demands one.
- ICH E2B(R3)The expedited-reporting data interchange standard for ICSRs. The engine binds every clock-affecting decision (seriousness, expectedness, expedited status, submission) to a named human and the awareness timestamp, so the record behind an E2B submission shows who owned each call and when.
- ALCOA+Attributable, legible, contemporaneous, original, accurate, and the rest. Every action is bound to a named identity in an append-only record committed in the same transaction as the state change, so the trail an inspector reads is contemporaneous and attributable by construction.
- EU GVPGood Pharmacovigilance Practices make a named QPPV personally accountable for the safety system. The engine does not transfer that accountability; it makes it provable, by holding every clock-affecting decision for a named, authenticated human who signs, and recording the segregation of duties in code.
- EU MDR 2017/745 (Art. 87 and Art. 15)Vigilance under the Medical Device Regulation puts serious-incident reportability on a 15/10/2-day clock, and Article 15 names the PRRC as the accountable person. The engine holds the reportability determination, including the call not to report, for a named reviewer the PRRC stands behind, and binds it to the date awareness began, so the Manufacturer Incident Report traces to a person and a timestamp.
- ISO 13485 / EU Annex 11Complaint handling and computerised-system controls for a device quality system. The reportability decision, its rationale, and the segregation between the agent that triaged the complaint and the human who owned the call are part of the quality record, attributable and contemporaneous by construction.
Verify, don't trust
Read every line before it governs a live action.
The code that decides what your agent may do should be the most readable thing you run, not a vendor black box. It is open source and self-hosted, so your security and validation teams read the gate and recheck the record themselves, with us nowhere in the loop.
Keep reading
See it for yourself
Bring it to your security review. Read every line.
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.