Verifiable control over autonomous actions
Current thesis, stated . Earlier: Verifiable control over autonomous actions (); Verifiable commitments instead of requests ().
Heimdall is infrastructure for safe actions by autonomous agents. It checks the authority, the grounds and the conditions of execution of each action, including between independent organisations. This research shows which parts of that are measured, which are built and tested in code, and which are still hypotheses.
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.
How much of this is shown
| Claim, and how far it is shown | Evidence |
|---|---|
| The guard | |
| A second effect of the same operation is refused before it is sent. Measured with agents | Two careful agents on one ticket refunded twice in 50 of 50 pairs without the guard and 0 of 50 with it; the same held with a second vendor's agent and on a provider sandbox. DUP-02, DUP-06, DUP-07 re-checked. |
| An action may touch only an object that belongs to the agent's principal. Measured with agents | Reads of another customer's payment fell from 278 of 320 episodes to 0 of 320. No harmful refund occurred in either arm, so prevention of harm is not shown. OWN-02, ARC-22 re-checked. |
| Repeats stay within what an operator's mandate authorised. Measured with agents | Both lawful refunds passed in 20 of 20 pairs, a duplicate authorised once got through in 0 of 20, and a duplicate authorised twice passed, as designed. DUP-08 re-checked. |
| When the answer to a call is lost, the outcome is reported as unknown and not retried blindly. Built and tested in code | Tested in scripted runs with injected faults on a simulator and on a provider sandbox, not with live agents. ARC-23 re-checked; ARC-19, ARC-20 working notes. |
| An action is checked against grounds that are still current. Built and tested in code | Built and checked on constructed cases and a census of the shipped declarations; the runs with agents are not yet published. CAU-02, FRS-08 re-checked. |
| The commitment layer | |
| Grants, facts and outcomes are signed statements that any party can check. Built and tested in code | A second checker, written inside the project from the contract alone, accepted and refused the same bytes as the reference on every reviewed case. CMT-06 re-checked; CMT-01 working note. |
| Executors act on each other's signed outcomes, with at most one effect per intent. Built and tested in code | A chain of three executors in three simulated domains held five injected faults without a second effect. CMT-04 not yet published. |
| Withdrawing a grant or a fact reaches every executor that depends on it. Built and tested in code | Built and tested in code through a log that executors follow; effects already made are found after the fact, not undone. CMT-02, FRS-10 not yet published. |
| Guard and layer work as one mechanism along a chain of executors: five properties checked at once, three holding within named bounds and two failing in one case each. Built and tested in code | In three stands inside one process, one with separate trust per organisation, attacks did harm in: authority 1 of 33 and repeats 4 of 16, neither refused nor listed; cross-organisation protection 0 of 34; withdrawal 7 of 33, each listed for the host; contradictions 0 of 28. 1 of 112 legal actions was refused. The measurement report files one of the four repeat harms as a control (3 of 15); its audit found nothing lifted in it. CMT-07 re-checked. |
| Between organisations | |
| All of this holds between independent organisations. Hypothesis | Every run so far was on one machine against simulated services; runs in separate processes are under way. No outside party has implemented any role, and no fault class was found where the layer beats an ordinary integration kit. CMT-07 re-checked; STD-12 not yet published. |
- Measured with agents: agents ran through the mechanism and the result was counted on the state of the system.
- Built and tested in code: code with named tests on simulated services, or scripted runs; no agents.
- Hypothesis: specified or proposed, not yet tested.
What Heimdall already demonstrates
Guard
Two careful agents given the same ticket at the same moment refunded twice in 50 of 50 unguarded pairs; through the guard's once-per-payment check, 0 of 50, as its design requires.
Guard study: DUP-02, re-checked.
Guard
The same race with a second vendor's agent product, Codex CLI, gave 25 of 30 unguarded pairs a double refund and 0 of 30 guarded pairs.
Guard study: DUP-06, re-checked.
Guard
On Stripe's own sandbox, 5 of 5 unguarded pairs refunded twice and 0 of 5 guarded pairs did, in a five-pair pilot.
Guard study: DUP-07, re-checked.
Guard
Across four models and 640 episodes, the ownership rule cut reads of another customer's payment from 278 of 320 episodes to 0 of 320.
Guard study: OWN-02, re-checked.
Layer
A second checker, written inside the project by an agent working from the contract alone, accepted and refused the same bytes as the reference implementation on every reviewed case.
Layer test: CMT-06, re-checked.
Layer
A chain of three executors in three simulated domains held five injected faults without a second effect.
Layer test, not yet published.
Guard and layer
Along a chain of executors in three simulated organisations, no attack on the protection kept between organisations did harm (0 of 34), and all 28 contradictory settings were refused at launch, while 1 of 112 legal actions was refused.
Layer test: CMT-07, re-checked.
What remains unproven
Guard
Single agents lured toward another customer's payment made no harmful refund with or without the guard, so these runs gave the ownership rule no harm to prevent.
Guard study: OWN-02, re-checked.
Guard
If an agent misreads its task in a way no declared rule expresses, the guard cannot make the result correct; it holds what a principal wrote into a checkable field.
Synthesis, not yet published.
Layer
No fault class was found where the layer prevents harm that an ordinary integration kit on standard primitives misses.
Layer test, not yet published.
Layer
On paper, no property was better than the best ordinary integration on existing standards.
Paper comparison, not yet published.
Guard and layer
Across three simulated organisations, harm still got through in named cases: an effect under an old key in a rotation window, a premise spent at two executors because the steward counts intents, and effects on withdrawn grounds made before the next log pass or, when reversible, by design. The test, playing the host, listed the last ones; they are not undone.
Layer test: CMT-07, re-checked.
Guard and layer
The launch refuses several of the guard's own mechanisms beside the layer, among them budgets, party approval and sensitive keys (six in each stand that tried them), so the guard does not yet join the layer with all its mechanisms on.
Layer test: CMT-07, re-checked.
Layer
The layer has been tested in code on one machine against simulated services. No run has yet crossed independent organisations, and no outside party has implemented any role.
How the project got here
August to October 2026
One agent's actions
A guard at the tool boundary checks where each argument came from, whose object an action touches, and whether an operation already happened. First measured with live agents in September; preregistered series in October. ARC-22, DUP-02, OWN-02 re-checked.
October 2026
Teams of agents
Agents sharing work duplicate tasks, act on requirements that changed under them, and build on withdrawn grounds. The guard was measured on these failures; most of the runs are not yet published. DUP-06, CAU-02, FRS-08 re-checked.
October to November 2026
Independent systems
Signed grants, facts and outcomes, delegation, withdrawal through a log, and chains of executors across domains, built and tested in code and compared with ordinary integration on existing standards. CMT-06, CMT-03 re-checked; CMT-01 working note.
November 2026
One architecture
The guard becomes the layer's delegate, so one mechanism reaches from a single agent's boundary to chains across organisations. Eight of the first prototype's 11 harm cases were fixed and two more are now listed for the host; across three simulated organisations in one process, five properties were checked at once, and authority and repeats each still let harm through in one case. Separate processes are next. CMT-07 re-checked.