A human clicks approve. Somewhere downstream, an agent runs a tool call. In most systems these are two separate records, written at two separate times, connected by nothing stronger than the fact that they happened close together. The approval says a payment of 4,000 to vendor X was authorized. The execution log says a payment went out. You are trusting that they describe the same payment. When they do not, the audit trail still looks clean, because a log near an approval reads exactly like a log of the approval.
The gap is small in wall-clock time and large in consequence. Between the moment a reviewer approves an action and the moment the runtime executes one, the arguments can drift. An amount changes. A recipient address is swapped. A destructive flag that was not in the request appears in the call. A retry fires the same approved action a second time. None of this requires malice. Agents rewrite plans mid-execution, orchestration layers replay messages, and a retry loop with the best of intentions will pay an invoice twice. The reviewer approved a description of an action. What ran was a different action that happened to occupy the same slot in the log.
An approval log and an execution log, kept side by side, cannot close this gap. They are two assertions about the world with no cryptographic link between them. You can read both and still not know they refer to one act. Most audit trails are two such assertions and a hopeful reviewer.
Binding removes the trust. The exact action and its exact arguments, in canonical form, are captured at the moment of approval and hashed. That digest is what the human approves, and it is what the runtime is permitted to execute. Before the action runs, the runtime recomputes the digest of the call it is about to make and checks it against the approved one. Same bytes, or it does not run.
Concretely, Athena canonicalizes the action payload with RFC-8785 so the same logical call always serializes to the same bytes, computes a digest over that form, and covers it with an ML-DSA-65 signature under FIPS-204. The approval is a signed statement over the specific arguments, rather than a row in a table that says approved: true, which is what most systems mean by an approval. Change the amount by one unit and the digest changes, the signature no longer verifies, and the binding breaks visibly.
Two properties come with it:
Most controls check that an action resembles what was approved. The category matches, the vendor is on the list, the amount is under a ceiling. Resemblance is not identity. A payment to the right vendor for the wrong amount passes a similarity check and fails a binding check. The cases that slip through are the ones that look right and are not. Binding asks a narrower question with a definite answer. Is this the action a human approved, byte for byte? Yes or no.
Binding fixes the identity of a single action. Scope and budget gates bound what the set of approved actions can do. Scope constrains which tools, endpoints, and resources an approval reaches, so an approval for one operation cannot be spent on another. Budget tracks a cumulative ceiling, so a series of individually valid approved actions cannot add up past a limit a reviewer set. Each gate evaluates before execution and writes its decision into the same record as the action it governed. Intent and enforcement land in one place instead of two systems that have to be reconciled later.
The approval, the arguments, the scope and budget decisions, and the execution outcome seal into a single record. Each is a self-contained proof: the canonical bytes, the digest, and the ML-DSA-65 signature travel together. A verifier recomputes the digest from the canonical form and checks the signature. No call to Athena, no network, no trust in the vendor who produced it. This is a single-record proof, not a shared ledger of everything. You verify the one act you are asking about.
The result is tamper-evident. It does not prevent anyone from writing a false approval, and it does not make a deployment compliant. It produces candidate evidence that maps onto what DORA, NIS2, ISO 42001, and SOC 2 reviewers ask for, and it renders cleanly for OSCAL-based workflows. We do not issue legal opinions or grant certification.
Stop storing an approval and an execution and hoping they match. Bind them. Make the approved action and the run action the same bytes, spendable once, verifiable by anyone offline. If your audit trail cannot answer "did the thing that ran equal the thing a human approved" with a signature instead of a shrug, the gap is still open.
