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, answer a customer. 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.6 · working prototype · where this stands →
- pay $800 → Acmematches open order · within limitsALLOW
- administer morphine 10mg2nd dose in 24h · under capALLOW
- e-file motion, case 24-1187waiting for supervising partnerHOLD
- email 4,200 customer recordsexport refused outrightDENY
- radar sweep, sector 7emissions not authorizedDENY
One checkpoint, five different agents: payments, a hospital ward, a law office, customer support, a radar console. 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 it buys you
Three things you get that you don't have today
An agent you can approve
The worst case is bounded by a policy your risk team approved, not by whatever the model happens to do. Approval becomes possible because the question is answerable.
Audit evidence, produced automatically
Every action and every refusal lands on a record an auditor can read. You have to produce this evidence anyway; the gateway produces it as a side effect of normal operation.
One switch, in your hands
A person approves exactly where you require one. An operator can stop everything not yet executed with a single switch, and the agent has no way to release its own actions.
Why the checkpoint
How an AI agent fails
Different failures with 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.
Not always the best model
Model choice is a business decision: cost, latency, privacy, or fine-tuning can all argue for something other than the largest frontier model. The checkpoint has to hold for the model you actually run, not for the best one available.
There is one more assumption to give up. With every technology we are used to, software included, each generation was more reliable than the last, and plans could rely on that. Nobody can promise the same for language models; their path is unknown. A control worth having must not depend on knowing it.
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 it holds wherever the models go.
The idea
A familiar procedure, applied to a new kind of worker
Human fallibility is an old and well-managed problem. We have spent centuries building institutions around the ways people fail, and the tools are older than the modern company: the ledger, the counter-signature, the spending limit, the audit. A clerk can be careless, confused, or dishonest, and the institution survives it, because it is the procedure, not the clerk's judgment, that bounds the damage.
AI agents are being deployed without that inheritance. An agent is often wired straight into live systems with privileges a trained and trusted employee would never be given: no counter-signature, no spending limit, no ledger anyone reads. The failures described above are already routine experience, and the privileges keep growing anyway.
Stonefold closes that gap. It applies the same structure to agents, in software. Spending limits, four-eyes approval, segregation of duties, a complete ledger of every action: these are the controls your auditors already require, enforced mechanically on everything an agent attempts. The rules live in a short, readable policy file that a reviewer approves, and the enforcement happens outside the AI, where no instruction hidden in an email or a document can reach it.
A distinction that matters
It is not a decision engine
Banks and insurers already run engines that decide things: credit scoring, fraud detection, pricing, collections. Those systems answer a business question: what should we do about this customer or this transaction? Stonefold answers a different one: what is this AI actually allowed to do, right now, on your systems? One judges the transaction; the other governs the actor. The same split holds outside finance, wherever a system of record or a rules engine already makes the business decisions.
Your decision engine decides what the business should do. Stonefold decides what an AI is allowed to do — and makes sure nothing else happens.
Follow one request through both. A customer asks an AI assistant to raise their card limit to $12,000.
- The decision engine answers the business question. It scores the request: approvable up to $12,000. It would give the same answer about an application a human clerk handled, and its job ends with the answer.
- Stonefold governs the act. The agent moves to make the change. On its own authority this agent may change limits only up to $5,000, so the $12,000 change waits for a named officer, executes on their click, and lands on the audit record together with the approval.
- When the two differ. An instruction hidden in a document tells the agent to raise a different account's limit to $50,000. No decision engine is consulted; the agent never asks for a decision, it simply acts. This is the case Stonefold exists for: the action exceeds the agent's mandate and matches no approved decision, so it is refused before it touches the account, and the attempt is on the record.
The two run in sequence and answer different questions; neither replaces the other. Stonefold sits in front of the systems you already run, including the decision engine, the way a spending limit sits in front of a clerk, however good the advice the clerk was given.
How it works
One checkpoint, in one picture
The only path. The agent cannot touch your systems directly; every action it takes is a request to the gateway. There is no second door for an attacker to find.
Rules, not judgment. The gateway 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.
Proof
The same agent, with and without the checkpoint
A real AI agent (Claude) processes the same invoice inbox twice. The only difference is whether Stonefold is in the path. The demo uses payments because everyone can read an invoice; the mechanism is the same in every domain below.
The full demo, including the kill switch and the approvals queue →
The same checkpoint, wherever an agent acts
Payments is only the demo. These are the deployments it is built for, and every card links to a real, reviewable policy in the open specification, not a mockup.
Payments & back office
the riskA fake invoice in the inbox, an invoice paid twice, a supplier's "changed" bank details.
held by policyA payment must match an open purchase order, larger amounts wait for a manager, and sanctioned destinations are refused.
The policy behind the demo →Clinical operations
the riskA ward assistant misreads a chart, or a poisoned note tells it to pull sealed records or repeat a dose.
held by policyDose limits per patient counted by the checkpoint itself, records scoped to the ward, and prescribing refused outright.
The worked policy →Industrial & physical systems
the riskA command to real machinery, fired at the wrong moment, that no one can roll back.
held by policyHard limits on physical parameters written in policy rather than in the prompt, actions allowed only from safe declared states, and an operator stop that nothing can override.
The worked policy →Legal & privileged records
the riskAn assistant reaches across client boundaries, and privilege is gone, along with the engagement.
held by policyAccess scoped to one client's matters, filings only with a supervising partner's approval, and every attempt on the record, including the refused ones.
The worked policy →Customer support & personal data
the riskOne planted instruction in an uploaded document turns a helpful support agent into a data leak.
held by policyReads limited to the customers assigned to the signed-in rep, recipient domains on an approved list, and export refused outright, a refusal that planted text cannot lift.
The worked policy →Defence & command decisions
the riskA manipulated feed or a misread situation pushes an assistant toward actions that must never be a machine's call.
held by policyEngagement is refused by default and becomes possible only under a declared rules-of-engagement state, with positive identification and two separate human authorizations. Authority stays with people.
The worked policy →Where to start
Three situations this was built for
An agent already holds credentials on your platform
Put the checkpoint in front of it in shadow mode: it enforces nothing and records what it would have stopped. Read that trail, then decide.
How interception works →Your agent pilot is stuck in security review
What unsticks it is a short, readable policy your reviewer can sign, plus an audit record for everything the agent attempts.
Start from a worked policy →You ship a product that embeds agents
The specification, the registry generator, and the conformance kit are open. Implement the gateway in your own stack, or embed this one.
Read the specification →Where this stands
Early, and honest about it
The specification is an open RFC at v0.6. The gateway is a working prototype: it runs the demo above and passes 552 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.