AI agents · bring your own model
Agents you can defend in an audit.
The hard question about AI agents is not what they can do. It is what you can show, afterwards, about what they did.
We build agent deployments where every command is checked against an allowlist, every refusal is logged with its reason, and agent actions can be sealed into receipts you keep. Bring your own open-weights model and run it on hardware you control.
commands our own agents attempted that the gate refused, since 2026-05-12
commands it allowed and ran in the same period
attempted force-pushes, all refused
From our own command log as of 2026-09-19. It is an internal record, not something you can open.
What exists today
Each piece, with its real status.
A command gate with refusals on record
Every shell command our own agents attempt goes through an allowlist. What is not allowed is refused, and every attempt, allowed or refused, is logged with the reason.
Scope tiers enforced in code
Actions are tiered (passive, authorized program, opt-in, contracted work). An action above its tier raises an error and is logged; it is not a warning in a prompt.
Receipts for agent actions
The prompt, response, tool calls and cost of one agent interaction are fingerprinted into a Counterfoil receipt you keep. Tested; connecting it to a live agent in your path is the next step.
Post-quantum keys
ML-KEM-768 and ML-DSA are implemented and tested for payload and at-rest protection. Encrypting the traffic between agents with ML-KEM is implemented in code but not deployed.
Agreement across several nodes
A fault-tolerant consensus reference implementation runs on one machine. It is not deployed across separate nodes.
Identity bound to hardware
Today agent identity is keyed with HMAC. Binding it to a hardware root of trust is on the roadmap.
In use means running in our own stack today. Built means implemented and tested but not running for anyone else yet.
What a record looks like
The refusal is the point.
One real interaction from our lab, on 30 September 2026, and the first run, not a chosen one. An open-weights model on our own machine was given a task and a shell tool. The command it proposed does not even do the task, and the gate refused it anyway: the gate does not depend on the model being right. The whole exchange was sealed into a receipt.
llama3.2:latest (open weights, run on our own machine) · model digest a80c4f17acd5 · temperature 0, seed 7
WHAT THE MODEL REPLIED
{"command": ["git", "fetch", "--all", "--force"], "why": "Fetch the latest changes from all remote branches to update the local repository."}
WHAT THE GATE DID
git fetch --all --force
REFUSED: no rule for git fetch
Nothing ran: the gate was in check-only mode.
The receipt holds fingerprints, not the texts: your prompts and your data stay with you, and anyone holding a text can prove it is the one that was sealed.
The version of this record your organization keeps, sealed so that an edit shows, is Counterfoil.
What we do not claim
Said plainly.
- We have not yet deployed this for a client.
- The command log is an ordinary database table: it records every attempt, but it is not tamper-evident by itself. Sealing records into receipts is what Counterfoil adds.
- We do not claim immunity to prompt injection. The gate limits what an agent can do; it does not make the model trustworthy.
Who it is for
Organizations that cannot send their data to a cloud AI.
Banks, insurers, healthcare, government, defense suppliers, and law firms working under data-localization rules or client confidentiality. If that is you, tell us what your agents need to do and what they must never do.