Control for AI agents
The AI proposes.
A machine you control disposes.
Companies are starting to let AI agents take real actions in their systems: pay an invoice, update a record, adjust a machine, close a support ticket. An agent can be tricked by what it reads, and it makes mistakes even when nobody is attacking it. Stonefold is the checkpoint between the agent and everything it touches: each action it attempts is checked against rules your organization approved, the sensitive ones wait for a person, and every attempt is recorded.
The question changes from “do we trust the AI?” to “do we accept this policy?” — and reviewing a policy is work an organization already knows how to do.
open source · apache-2.0 · specification v0.4 · working prototype · where this stands →
- pay $800 → Acmematches open order · within limitsALLOW
- close result #4411 as escalatedhanded to a person, not buriedALLOW
- change supplier bank detailswaiting for finance controllerHOLD
- delete db-cluster prod-7deletion protection setDENY
- read provider master keystatic key, no expiryDENY
One checkpoint, three systems we built and tested: supplier payments, a clinical results worklist, cloud infrastructure. Green means the action ran, amber that it waits for a person, red that it was refused. Each line is also an audit record.
What we measured
The same job, two models, opposite behavior
The clearest argument for putting the check outside the model is what happens when you change the model and change nothing else.
We built a working model of a finance department — an invoice mailbox, a purchase-order system, a bank — and planted one fraudulent email: a supplier asking for its bank details to be changed. Then we pointed agents at it, changing nothing except which language model was driving.
The capable model never fell for it: it worked out on its own that the email did not fit the pattern, and named it as attempted fraud. The small, cheap model fell for it in all twelve of twelve runs, attempting the bank change before reading anything that might have contradicted the email.
Neither result is a safety property — nobody knows which way the next model or the next prompt will fall. What made the outcome the same in both cases was one rule outside the model: a bank-detail change waits for a named human. With that rule in place, no money reached the attacker under either model.
Without the checkpoint, your exposure is a property of the model you happened to choose. With it, it is a property of a policy a person read and signed, and it holds for the cheap model you run at volume as well as for the expensive one you demoed with.
Measurements against systems built to behave like real ones, with the failures allowed to happen before any control was written — not a benchmark of the models. The full account, including what the fraud looks like, is in the use case →
Why the checkpoint
How an AI agent fails
An agent is often wired straight into live systems with privileges a trained and trusted employee would never be given. The failures below have different causes and one property in common: none of them can be fixed by asking the model to behave. The check has to sit outside the model.
Tricked by what it reads
An email, a document, or a web page can carry planted instructions the agent may follow. This problem is unsolved, and defenses inside the model lower the odds without bounding them.
Invents what it doesn't know
Where information is missing, a model fills the gap with plausible detail: an account number, a delivery date, a dose. The invented answer arrives with the same confidence as a correct one.
Imprecise by construction
A language model picks each word by statistical plausibility, so an occasional wrong action is part of normal operation, not a malfunction. Better models lower the rate; none reaches zero.
Not guaranteed sincere
In evaluations, models have been observed deceiving their reviewers and working around constraints. Nobody can promise you this never reaches production, so a control must not depend on that promise.
An AI weaker than a person has to be checked because it errs, and an AI stronger than a person has to be checked because you must stay in charge of it. The checkpoint assumes neither human intelligence nor human sincerity, so nothing about it has to change when the models do.
How it works
One checkpoint, in one picture
The only path. Every action the agent takes is a request to the checkpoint: the agent holds no credentials of its own, and the checkpoint holds them all. Making this the only route is a deployment requirement, and the use cases spell out what that takes.
Rules, not judgment. The checkpoint is ordinary software applying your written policy the same way every time. No AI takes part in the enforcement decision. Why an AI reviewing an AI is not enough →
People where you want them. Actions above your thresholds wait for a named person. Every attempt, including the refused ones, becomes an audit record. Named approvers, refusals on the record, and a switch that stops everything are also exactly what an auditor asks to see when the question is who was overseeing the system.
The full mechanism, one tutorial at a time, in the developer's guide →
The obvious objection
Isn't this just a policy engine?
Partly, yes. At the center sits a policy decision point: a request comes in, rules are evaluated, a verdict comes out. OPA, Cedar, or an API gateway with an authorization plugin can render such a verdict, and if that were the whole job, the right answer would be a config file, not a product.
The short version, if you are not an engineer: deciding yes or no is the easy part. The product is everything that has to happen around that decision — holding an action until the right person answers, keeping the credentials, remembering what was already spent, writing the record. If the rest of this section reads as too technical, this paragraph is all it says.
The product is the machinery around the verdict, which a general-purpose policy stack leaves as integration work — and once the caller is an autonomous agent, that machinery is most of the work:
Hold is a first-class outcome: an action can wait for a named approver with a timeout, staged so the agent cannot release it, and the kill switch shares a transaction with dispatch so a halt is not a race.
The gates need state, and the checkpoint owns it: daily totals, an order line reserved so it cannot pay two invoices, the memory that something was refused earlier in the session.
Refusals are answers an agent can act on: what was refused and what would satisfy the rule, so the agent's next move can be requesting the approval instead of failing into a retry loop.
Bulk calls are decided per item: the items that pass are applied and the refused ones are named in the reply, because refusing a whole batch of twenty just creates an outage.
The checkpoint holds the credentials and executes. A sidecar rendering opinions beside an agent that owns the keys was bypassed in our own testing in a fraction of a second; here the agent holds nothing.
The audit covers attempts, not just effects: everything the agent asked for, including everything refused, written transactionally with the effect. Provider logs only show what reached the provider.
You could assemble all of this from parts, the way you could assemble a database from files and locks. The claim of this project is that the assembly is one thing, with one spec and one conformance kit, so the same properties can be demanded of any implementation, including ours. The five-minute version of the argument is Why not just tools?
Two neighbors, neither a substitute: prompt-injection filters lower the odds of a bad proposal arriving, while the checkpoint bounds what any proposal can do; decision engines answer what the business should do about a transaction, while the checkpoint answers what this actor may do on your systems.
Worked use cases
Three places an agent takes real actions
Paying suppliers, cloud and platform operations, and clearing a work queue — each built as a working system and driven by a real agent. Three unrelated domains, and the control that carried the value was the same shape in all of them; the use-cases page names the pattern and shows why it keeps turning up.
The use cases → · A runnable demo → · How interception works → · The specification →
Watch first
Advisory mode
The checkpoint can run with every verdict recorded and none of them enforced. Two weeks of that record become a report for the people who decide whether to enforce — evidence a security reviewer can sign.
Where this stands
A working prototype, no production miles
The specification is at v0.4, versioned by what the test systems have actually earned — with one exception the spec itself names: v0.4 added advisory mode, which is implemented and conformance-certified but has not yet run a pilot. The gateway — which is what the code and the docs call the checkpoint — is a working prototype: it runs the demo and passes over 650 automated tests against real infrastructure, and it has no production miles yet. The conformance kit has so far been run against one gateway, our own. The project is one developer, building in public; the spec, the code, and the disagreements are all on GitHub.
What this stage needs most is readers, critics, and a first pilot partner. If your organization is weighing an agent deployment and sign-off is the blocker, this is a good time to talk.