ABERNATE
GOVERN | CONTROL | PROTECT
ABERNATE checks each action before it happens. Four rules have to agree, or the action does not run. A person has to clear a release, and that person can only say no. Every step writes a signed receipt, and a recipient who was given the right verification key can check it themselves.
Both figures are EMA's, from their April 2026 survey of 152 IT and security leaders, quoted from EMA's own published summary. Not our numbers and not about this product. Two further figures were on this page earlier today and have been removed: they came from trade-press summaries and could not be confirmed against the publishers.
Security review does real work. It decides which AI tools are allowed, which vendors clear procurement, and what data those tools can see. All of that is about what the agent is.
The gap that follows is not our observation. Four independent groups have described the same missing layer in 2026 alone, under four different names, and at least one has argued the whole category is aimed at the wrong place. Sources in the technical packet.
Then the agent runs. It calls an API, writes to a database, triggers a workflow, holds a document. Nothing sits between that call and the consequence, and more than half of agents in production run with no oversight or logging at all. A third of organisations say they could not immediately stop a rogue agent.
A reviewer has two options: hold the project, or let it through with the agent restricted. More than 80% of organizations report doing the second at least sometimes, and end up running a smaller version of what they paid for.
ABERNATE covers the part nobody checks: what the agent is allowed to do, at the moment it does it.
{
"mission_id": "legal-hold-sweep-4471",
"purpose": "Sweep a custodian folder under legal hold: catalogue
every file, hash each one for chain of custody, look
inside archives, and flag material appearing across
more than one source. No network access.",
"operational_status": "PASS",
"steps_executed": 4,
"receipt_chain": "VALID",
"release_required": true,
"released": false,
"squad_leader": "BLOCKED: no clearance recorded for
legal-hold-sweep-4471. Run the go/no-go
board and record a GO before release.",
"final_receipt_hash": "fc1244d6c1c8ff789c951f8be42b2627...",
"metrics": { "completion": 1.0, "success": 1.0,
"authority_coverage": 1.0, "receipt_integrity": 1.0 }
}
Output from the sample that ships with the package. Every step ran, every check passed, and it shipped nothing, because no human had cleared it. Success is not permission, and being able to show the difference is what the review is asking for.
An agent that clears review with its autonomy cut is not a win, it is the budget spent and the capability withheld. An agent still in review at month six is the same money with nothing to show at all.
Both happen for one reason: the reviewer has no control to point at, so the only levers left are delay and restrict. Give them a gate that refuses on the action itself, and a signed record of every refusal and every clearance, and the conversation changes from how much to take away to what evidence gets produced.
Regulatory exposure, audit cost and liability allocation all follow from this and none are ours to quantify. They are the buyer's arithmetic, not our claim.
No customer has measured a dollar of any of this, so no dollar figure appears on this page.
hello@abernate.com · the technical packet, on request
Permission is not one setting. Before an action runs, four separate questions have to answer yes.
A named human has the last word and can only say no. Their GO cannot push an action through a check that already failed, and a policy written without that gate is rejected the moment it loads, so no engineer disables it by forgetting it.
Every step writes a receipt, hash-linked to the one before it and signed. A step can cover many files, so this is a record per step, not per file touched. That file goes to the customer's lawyer, the SOC 2 auditor or opposing counsel. Each checks it with a command that ships in the package, against a verification key they were given separately. They still have to trust where that key and that package came from. What they do not have to accept is the operator's word that the ledger is unaltered.
The figures below came from one run against a public corpus that anyone can download. Not a demo folder, not a benchmark we built.
sha256 ddfaf383c97f393a7768943630ea01e6c3cfb9af4fbc02655a37a2f3680013d6The check ships in the package. reproduce.py downloads that tarball, verifies the sha256, grants the corpus through a contract it prints and then revokes, runs the sweep, and compares the five figures above against what it measured. Exit 0 means those five held on that machine. It takes about nine seconds.
One more thing happened on the way in, and it was not staged. The first attempt was refused before a single file was read: read path outside authority. No worker contract declared that corpus, so nothing touched it until one did. That is the gate working on data it had never seen.
46 of 46 tests pass from a cold extraction on Python 3.12. Standard library only. No dependencies, no network, no account, no GPU, nothing to host. The internal file manifest is generated from the folder and refuses when the two disagree, because a hand-typed count is what went wrong twice.
Sold outright or licensed. The transfer includes the source, the hashes, the provenance record, the full adversarial test corpus and every defect ever found in it, including the ones still open. Evaluation copies are confidential.
hello@abernate.com