The guard
The guard does not try to make an AI agent reason correctly. It limits what the agent's actions can do: before a tool call reaches a service, it checks the formal conditions it can see, and refuses the call or holds it for a person when they fail.
What it checks
| Check | Studies |
|---|---|
| One effect per operation | 8 published |
| Whose object it is | 6 published |
| Where each argument came from | 2 published |
| Whether the grounds are still current | 4 published, 30 not yet published |
| Mandates, limits and people | 4 published |
| The rules themselves | 3 published |
| What it costs | 4 published |
| Where it stops | 3 not yet published |
An example
An agent is asked to refund one customer’s payment. It may pick the wrong customer, take a payment id from a note in the ticket that nobody checked, refund a payment that another agent refunded a second ago, or act on a policy that changed this morning. The guard sees the call before the service does. It checks that the payment belongs to the customer this session works for, that the id came from something the session read, that no refund of this payment is already recorded, and that the grounds the action rests on are still current. If a check fails, the call is refused or held for a person, and nothing reaches the service. None of this depends on how well the model reasons.
Where it sits
The guard runs as an HTTP gateway in front of a service’s API, or as a proxy in front of an MCP server. Each service is described by a declaration: which calls change state, which fields identify an object and who owns it, and what a read returns. The same checks run for refunds, bookings, GitHub issues and budgets that count operations instead of money. Refunds are the main test domain because a duplicated or misdirected refund is easy to count; the guard is not a payments product.
What the evidence shows, and what it does not
Each check below links to the studies that test it, labelled with the question each one answers. Where the guard stood between agents and the service, duplicated refunds and reads of another customer’s objects went to zero, as its design requires, while unguarded agents made them. Whether holding every check at one boundary is worth more than building each one separately has not been measured yet.
One effect per operation
The guard records each operation before sending it. A second request for the same operation is refused before anything is sent, and when an answer is lost the outcome is reported as unknown instead of being retried blindly.
Without the guard
50 of 50 refunded twice
With the guard
0 of 50 refunded twice
8 published: 6 predictions held, 1 failed, 1 measurement; 6 re-checked.
What three Stripe SDKs retry under injected faults
Better than simpler options?
Whose object it is
An action may touch only an object this session saw belong to its principal: the customer, the account or the repository the agent works for.
Without the guard
278 of 320 read another customer's payment
With the guard
0 of 320 read another customer's payment
6 published: 1 prediction held, 1 no difference, 3 mixed results, 1 measurement; 4 re-checked.
Before the series: a strong model opens another customer's payment to decide not to refund it
Better than simpler options?
Where each argument came from
Every identifier and amount must trace to something read in the session, and an action on all of a set needs the complete set, not its first page.
2 published: 1 failed, 1 mixed result; none re-checked yet.
Do real API specifications publish a snapshot and completeness bit?
Where does it stop?
Whether the grounds are still current
An action that rests on a value read earlier is checked against the value now, so a withdrawn or amended requirement does not carry an action through.
4 published: 2 predictions held, 2 measurements; 2 re-checked.
How far an action-time reread reaches in the shipped declarations
Where does it stop?
Better than simpler options?
And 30 more studies, not yet published.
Mandates, limits and people
Operator mandates and budgets bound what may happen, counted in money or in operations, and an action above a threshold is held for a person to decide.
4 published: 1 prediction held, 3 measurements; 4 re-checked.
Agents asked to justify a held refund to a human reviewer: three trials
Better than simpler options?
Second delivery of a ticket while the provider holds the refund for approval: two single pairs
Better than simpler options?
A documented live path blocked at the estimate step: an incident report
Where does it stop?
The rules themselves
The guard enforces what its declarations state. Probe stands and a model of execution authority check the declarations themselves.
3 published: 1 prediction held, 1 failed, 1 measurement; none re-checked yet.
What it costs
Time per action, what the guard keeps about people, what an agent can learn from a refusal, and whether the guard changed what agents spent.
4 published: 1 prediction held, 1 failed, 1 mixed result, 1 measurement; 2 re-checked.
What a tool-call guard keeps about people: a marker census of its own stores
Where does it stop?
What an agent learns from a refusal over stdio: body versus timing
Where does it stop?
The guard did not save model spend: a cost reading of 317 saved sessions
Where does it stop?
Where it stops
The guard holds what a principal wrote into a checkable field, and links made by value. If an agent misreads its task in a way no rule expresses, the guard cannot make the result correct.
3 studies, not yet published.
Next tests
- The duplicate-delivery result in a second, non-money domain, with two agents booking one slot.
- What the once-only check adds at the layer's executor, against simple keys, a lock and an ordinary integration kit.
- Whether holding every check at one boundary is worth more than building each one separately.
- Agents misled about their task, with and without a grant signed by the principal.
- Coding agents' replies after a refusal, coded blind across vendors.