--- title: "Glossary: Agent action assurance" canonical_url: "https://tokenobserve.com/glossary/agent-action-assurance" published: 2026-09-02 last_updated: 2026-10-21 --- # Glossary: Agent action assurance Agent action assurance is the practice of proving that the exact authority delegated for one agent action was the authority actually used, and that the action produced the business effect it reported producing. Its subject is the consequential, externally observable action (a refund, a deployment, an outbound email, a ticket transition, a row written to a system of record), where a provider returning a success status is evidence that a request was transported, and not evidence that anything happened. ## Also called - action assurance - AI action assurance - agent effect assurance - authority and effect assurance ## In practice 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 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 which candidate, policy, path and forbidden target were tested. The accurate 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. It should prefer 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 exist and have been exercised, and a verifier the same party pinned is not independent attestation. Without them, an auditor is misled rather than informed. ## Example: 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. ## 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), 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 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.