Verifiable control over autonomous actions

The problem

An agent that can call tools can refund a payment, book a slot, close an issue or change a record. It can also refund the wrong customer, use an identifier from a note nobody checked, repeat an operation another agent already made, or act on a requirement that was withdrawn an hour ago. Careful agents make these mistakes too: in our runs, agents that read the state before acting still duplicated effects when two of them received the same task at once.

Two mechanisms

The guard sits where an agent’s tool call becomes an effect: as an HTTP gateway in front of a service’s API, or as a proxy in front of an MCP server. Before a call is sent, it checks formal conditions against a declaration of the service: whose object it is, where each argument came from, limits and mandates, whether the same operation already happened, and whether the grounds of the action are still current. It does not try to make the model reason correctly; it limits what the model’s actions can do. How the guard works.

The commitment layer extends that discipline across independent systems. A principal signs what is allowed, a source signs what is true, and an executor makes the effect once and answers with a signed outcome. Any party holding the records can check who allowed an action, what it rested on and what happened, without relying on what an agent says. Inside the layer, the guard acts as the delegate that turns a judged call into an intent. How the layer works.

Three questions we keep apart

Each study answers one question, and its page says which.

• Does it work? The mechanism against no mechanism, or against its own specification.
• Is it better than simpler options? The mechanism against a prompt, a key, a lock, an ordinary integration or an existing standard. Where a simpler option did as well, the mechanism still works; it is not unique.
• Does combining help? Whether holding several checks at one boundary, or joining systems through one layer, adds something separate mechanisms do not.

A result of no difference usually answers the second question, or shows that a setup produced no harm to prevent. It is not by itself evidence that a mechanism fails.

Where it stops

The guard holds only what can be stated as a checkable rule. The layer has been built and tested in code against simulated services and has not yet run between independent organisations. Money is one test domain, chosen because a duplicated or misdirected refund is easy to count; bookings, support tasks, GitHub issues, requirement tracking and document review are others. Neither mechanism is a payments product.