Agent action assurance
also called action assurance · AI action assurance · agent effect assurance · authority and effect assurance
The term names what is left after the neighbouring categories take their part, and it is deliberately narrower than any of them. Identity systems prove who an agent is. Security systems inspect its traffic. Gateways carry the request. Observability describes what the run did. None establishes that the authority delegated for this one action was the authority used, or that the action had the effect it claims. Compressed to three beats: before an agent acts, prove authority; after it acts, prove effect; when systems fail, prove the control survived.
Proving authority means binding a decision to a specific action rather than to a session or a role. The mechanics that make this real are unglamorous and each closes a concrete hole. A human approval bound to a digest of the exact payload, single-use and expiring, so that approving a £40 refund cannot authorise a £40,000 one and an approval cannot be replayed for a second action. A delegation chain that intersects at every hop, so an agent cannot escalate by asking a higher-privileged agent to do what it was refused. And the policy, tool descriptor and contract digests recorded as they stood at the moment of the call, because a rule that was rewritten afterwards is not the rule that decided.
Proving effect is the harder half, and the reason is that a remote system cannot join your transaction. There is no common transaction protocol across the systems an agent acts on, so exactly-once execution across that boundary is not something a governing component can promise. What it can do is take a durable claim on the action’s business idempotency value before anything leaves, so a duplicate delivery is refused rather than dispatched twice; treat a timeout as an ambiguous state to be resolved by looking rather than by retrying, because a retried read is free and a retried payment is a second payment; and call a separate, pinned verifier afterwards whose observation must be fresh and post-dispatch before the run is recorded as committed. Where a rollback exists, the same scepticism applies to the undo: a system that can return a misleading success for the action can return one for the compensation, so the run should read compensated only when a distinct verifier has observed that it happened. Token Observe implements exactly that lifecycle as effect contracts, and states its own boundary in the same sentence — at-most-one dispatch from the governing point, not distributed exactly-once, with the downstream system still obliged to honour the idempotency key it is sent.
Proving the control survived is the beat most programmes never reach, and it is the one that separates a control from a claim. It means deliberately injecting the failures that would disarm the control — revoked identities, replayed approvals, stale workflow state, altered tool descriptions, an audit sink that has stopped accepting writes, clock skew, delegation loops, provider refusal combined with failover — and producing a report of exactly which candidate, policy, path and forbidden target were tested. The honest phrasing of such a report is bounded negative evidence: these specific bypasses were attempted against this build and refused. It is never universal proof that access is impossible, and a vendor who offers the second thing has not thought carefully about the first.
The output is a receipt, and receipts are where the category’s over-claiming concentrates. A useful one binds the installation and receipt identifiers, the human sponsor and the attenuated delegation chain, the agent identity, the workflow and a digest of the exact payload, the policy and descriptor and contract digests, the approval identity with its scope, expiry and single-use nonce, the execution attempt and observed outcome, the postcondition and compensation verdicts, and the audit or anchor references — preferring typed claims and digests to raw prompts, arguments and results, so the evidence does not become a second copy of the data it describes. Mutating any bound field should break verification. But a receipt is not independently verifiable until an offline verifier and a trusted key distribution mechanism actually exist and have been exercised, and a verifier the same party pinned is not independent attestation. Those two sentences are the difference between an auditor being informed and being misled.
The refund that timed out
An agent calls a refund tool. The call times out after thirty seconds. Two worlds are consistent with that timeout: nothing happened, or the refund was issued and the acknowledgement was lost. The agent framework’s default is to retry, and one of those two worlds makes the retry a second refund. Action assurance replaces the retry with a lookup. Before the first attempt, a durable claim was taken on the refund’s business idempotency value, so a duplicate dispatch is refused rather than sent. After the timeout, a separate verifier tool — pinned to its own approved descriptor, so it cannot have been swapped for something more agreeable — is asked what the refund ledger now says, and its answer must carry an observation timestamp after the dispatch and inside a freshness bound. Only if the postconditions match that observation does the run read committed. If the verifier is unavailable or its evidence is stale, the run reads unknown, which is a state somebody can see and act on, rather than an error that got swallowed on the way to a green dashboard.
What agent action assurance is routinely confused with
- Observability and tracing
- A trace records what the system reported doing, and it is written by the party being examined. Action assurance requires a second, separate observation of the world after the fact — a read-after-write against the system of record — precisely because the first report is the thing in question.
- Identity and access management
- An access decision authorises an attempt. Action assurance is about the attempt’s outcome: a valid access token, correctly scoped and correctly presented, is entirely compatible with an action that never happened, happened twice, or happened outside the bounds the approver had in mind.
- Guardrails
- Guardrails constrain what the model produces — refusal behaviour, output filtering, structured output validation. Action assurance ignores what the model said and examines what changed in the world afterwards. A perfectly guarded model calling a refund tool twice is a guardrail success and an assurance failure.
Related terms
AI agent governance
AI agent governance is the practice of deciding, outside the agent and before it acts, whether the authority it is about to exercise is authority somebody actually delegated to it — and of recording afterwards what it did with that authority in a form that survives the people who could edit it. What separates it from model safety, from observability and from identity management is where the decision sits: in the path the action must travel, where it can refuse, rather than in a policy document, a dashboard, or a nightly reconciliation.
Inline enforcement
Inline enforcement means the decision to allow, refuse, alter or hold an action is taken in the path the action must travel, before it takes effect, by a component the acting system cannot bypass or overrule. The alternatives — a rule the agent is asked to follow, a check inside the agent’s own framework, an alert raised afterwards — are advisory rather than enforcing, because in each case the party being governed is also the party enforcing.
Fail-closed
Fail-closed describes a control that denies the action it governs whenever it cannot complete its own check — because a dependency is unavailable, a required piece of evidence is missing or stale, a value cannot be evaluated, or the control itself is down. The opposite arrangement, fail-open, permits the action in those same circumstances, which turns every outage in the control into a temporary and silent absence of the control.
AI control plane
An AI control plane is the layer that holds the authoritative configuration for an organisation’s AI agents — which agents exist, who owns each one, what each may call, what each may spend, and what happens when a rule is broken — and that makes the configuration binding by sitting in, or being consulted by, the path those agents’ requests take. The name is borrowed from networking, where the control plane decides what should happen and the data plane carries the traffic that does it; the distinction matters here because a product can implement either half and still be sold under the same label.
Where Token Observe does this
The definition above is the field's, not the product's. This is the part of the product that implements it, for a reader who wants to see one.
Effect contracts
The action leaves once, and success is what a second pinned tool observed.
The downstream must enforce the idempotency key you send
Human approvals
One human decision, bound to one exact payload, spendable once.
An approval takes effect only when the agent retries
Audit chain
Every administrative act hash-chained; seal it under a key held off the box, and anchor it with a signature your auditor can check alone.
Unkeyed, a rewrite that re-hashes everything verifies clean
The terms next to this one
What the field is called, what its members have in common, and the one property that separates them from each other.
Definitions are the easy part.
The glossary is written to be useful whether or not you ever buy anything. If you have got to the point of deciding how to implement one of these in your own estate, say what your agents do and you will get a straight answer about what it would actually take.
no form · no qualification step · no sales desk · the other three ways in