November 1, 2026
There is a quiet assumption spreading through the IETF. It is the belief that if you can prove an AI agent was authorized to act, and you can prove the action left a cryptographically signed trace, you have solved the problem of AI governance.
This assumption is wrong.
It is not wrong because the cryptography is flawed. The cryptography is excellent. It is wrong because it answers the wrong question. Proving that an agent was allowed to act is not the same as proving that the agent decided correctly.
The Architecture of the Envelope
To understand the gap, look at what the IETF is currently building. Three distinct tracks have emerged in the AI agent governance space:
- Pre-Action Gates: The
verification.*family defines a fail-closed gate. Before an agent executes an action, it presents a canonical input to a gate. The gate returns a binary act/halt decision, signed with a cryptographic receipt. - Execution Envelopes: Frameworks like
AgentROAbind an agent's authorized scope at the session level. They use per-hop attestations to track delegation and produce execution receipts at every capability boundary. - Finality Layers: The DAS protocols introduce a "Candidate Act" model, where an AI output is held as non-effective until a protected pipeline validates provenance, factual support, and consequence.
These are all envelope architectures. They construct a boundary around the agent. They answer one question with high precision: "Did this action stay within the boundary we declared for it?"
They do not answer a different question: "Was the boundary itself correct, and can we prove why this specific decision was the necessary outcome given the inputs?"
If an agent acts exactly within its authorized scope, but its decision logic was corrupted, manipulated, or simply wrong, the envelope will still validate. The receipt will still be signed. The log will still be immaculate. And the action will still be a disaster.
The Vocabulary Collision
The industry has been sloppy with language. The word "replay" is currently being used to mean three entirely different things:
- Replay as Security: Preventing a malicious actor from reusing a valid capability receipt (replay attack prevention).
- Replay as Lineage: Verifying that a log has not been tampered with, and that the hash chain is intact (lineage verification).
- Replay as Reconstruction: The ability to take the exact inputs, the exact logic version, and re-run the decision to prove the output was necessary.
The IETF is standardizing the first two. The third is missing.
A system that cannot reconstruct the reasoning of a decision cannot be audited. It can only be described. And a description is not proof.
The Regulatory Disconnect
This semantic gap is not just an academic problem. It is a compliance liability.
Regulatory bodies are beginning to demand more than just logs. The EU AI Act Article 12 mandates record-keeping for high-risk systems, but record-keeping without the ability to replay the decision logic is just a filing cabinet. It does not enable "post-market monitoring" in any meaningful sense.
More urgently, the National Association of Insurance Commissioners (NAIC) is moving toward examination frameworks that ask insurers to produce a "Contemporaneous Action Record."
When an examiner asks an insurer to prove that an automated system made the right decision six months ago, a signed hash of the action is insufficient. The examiner will ask: "How do you know the system applied the rules correctly at that moment?"
Without deterministic replay, the insurer cannot answer. They can show what the system did. They cannot show why it had to.
What the Decision Contract Provides
The industry does not need another envelope. It needs a definition of what must exist inside the envelope.
The Decision Contract defines five conditions for a compliant record of an automated decision:
- Determinism: The same inputs must produce the same output.
- Replayability: Any independent party must be able to re-execute the decision logic against the retained inputs.
- Tamper-Evidence: Any modification to the record must break the cryptographic chain.
- Framework Mapping: The record must bind the decision to the specific regulatory rule it satisfied.
- Rationale: The record must contain the human-readable reasoning that produced the output.
These are not features of a product. They are the definition of evidence.
An envelope architecture provides condition 3. It provides tamper-evidence. The Decision Contract provides the other four.
The Missing Layer
The IETF is building the delivery mechanism for agent actions. That work is necessary and valuable.
But when the regulator asks why a decision was made, and the court asks how the system reached its conclusion, the envelope will be silent. It will only show that the action was permitted. It will not show that the decision was correct.
The layer that proves the decision was correct does not yet have a standard. It must be built. And it must be built on deterministic replay, not just cryptographic lineage.
A decision that cannot be replayed cannot be governed.
The standard for replay is not yet written. It should be.
The Jason Logic Group
https://seais-decision-core.onrender.com
thejasonlogicgroupllc@gmail.com
Top comments (0)