Define machine-verifiable approval-to-execution scope binding for SAFE evidence

[lumirosh]

Spun out of #5 at the author's request, where the transport mapping was in scope but these semantics were not.

Problem

SAFE's Evidence Preservation list requires members to retain human approval and intervention events. Preserving the event is not the same as preserving what it authorized.

Two of the RFC's reportable conditions depend on that difference: a system acting on a third-party system without authorization, and a system continuing to probe after detection. Both require a reader to distinguish four outcomes that today would be reported identically:

1. No valid authority existed.
2. Valid authority existed and execution stayed inside it.
3. Valid authority existed and execution left its scope.
4. Evidence is insufficient to determine which of the above occurred.

These are different control failures with different remediation. A member can satisfy every item on the Evidence Preservation list and still leave a reader unable to tell them apart.

Why this is not an upstream transport question

otel-genai#368 (draft) adds gen_ai.agent.governance.ref as a deliberately opaque, producer-scoped reference, with the referenced record's format, schema, lifecycle and validation explicitly out of scope. That looks like the right decision for a transport convention.

It also means the pointer exists and its contents are undefined. This issue proposes requirements for what a SAFE-conformant record behind that reference should establish. It does not ask OTel to parse it, and it does not propose a new transport.

otel-genai#159 (gen_ai.agent.paused / .resumed, with pause.reason: human_input) is the natural carrier for the approval moment itself.

Proposed requirements

Requirements, not a schema. Vocabularies can start small.

R1. Both operands preserved. What was approved, and what actually executed, must both be retained in a form that survives export to another party.

R2. Structured, not prose. The approved action should be expressed against a structured action vocabulary, for example a tool-call schema, rather than free text. The approved resource should use a stable identifier, for example the workload identifiers already proposed in the #5 mapping, rather than a human-readable name.

R3. Recomputable verdict. Any conformance result must be recomputable by an independent party. A recorded verdict must reference the comparison method and its version, alongside the normalized inputs and the evidence references used. A verdict without a stated method is an assertion, not evidence, and inherits exactly the problem this proposal exists to solve. This constraint was raised by @meshailabs in #5 and is adopted here.

R4. Authority validity is a separate question. Whether authority was valid, time-bound and not self-extended is the subject of #1. This issue assumes that question is answered elsewhere, and addresses only whether execution remained inside the scope that authority granted.

R5. Insufficient evidence is a reportable state. Absence of a determination must be distinguishable from a negative determination.

Relationship to existing work

• Add Temporal Authority and Self-Extension Denial to the SAFE Evidence Framework #1 temporal authority and self-extension: authority validity. Complementary, not overlapping.
• Support design-time control lineage in SAFE findings (design_coverage + design_references) #3 design-time control lineage.
• Specify a machine-readable baseline for the Evidence Preservation list: map it to OpenTelemetry GenAI semantic conventions #5 transport and identity mapping. This issue is the semantics that mapping deliberately did not settle.
• Add a pre-connection tool-trust attestation as an interoperable evidence type, expressed against the OTel GenAI conventions #6 pre-connection tool-trust attestation.
• Add an optional causal incident graph profile for reconstructable, mechanically verifiable SAFE findings #7 causal incident graph.

Prior art, with its limits stated

I maintain Open Decision Receipt, Apache-2.0, vendor-neutral: https://github.com/lumirosh/open-decision-receipt

Cited as prior art and as a worked example of the failure above, not as a solved standard and not for adoption. It records both operands, approval_scope on the authority block and actual_action on the execution block, and both are free-text strings. It therefore cannot mechanically compare them, and neither can anyone reading its output. R2 and R3 are what that implementation is missing.

Runnable lifecycle example: https://github.com/lumirosh/open-decision-receipt/tree/main/examples/end-to-end-artifact-bundle

[Rambi-2020]

A related evidence requirement may be worth making explicit here: authority lineage, execution-time authority revalidation, and post-action authorization reconciliation.

R4 appropriately separates authority validity from the question addressed by this issue: whether execution remained inside the scope granted.

There appears to be an additional evidentiary gap between approval and execution.

An action may have been validly approved and still no longer be authorized when the agent actually acts.

For consequential agent actions, the evidence record should therefore establish not only that approval occurred, but that the supporting authority remained valid at the point of execution.

Conceptually:

source authority → delegation → human approval → execution-time authority revalidation → action → post-action reconciliation

Immediately before consequential execution, the system should be able to establish that:

• the approving human or organization still possesses the required authority;
• the authorization has not expired, been revoked, superseded, transferred, or otherwise invalidated;
• the authority lineage remains intact;
• the scope originally approved still matches the action about to occur;
• no material factual condition underlying the approval has changed;
• no superseding instruction from equal or superior authority conflicts with the approval; and
• the action actually queued for execution remains within the previously authorized parameters.

If those conditions cannot be established, the prior approval should not automatically authorize execution. The action should return to the appropriate human authority for determination.

This addresses a time-of-authorization versus time-of-action problem.

A system may truthfully possess evidence that:

“This action was authorized.”

while being unable to establish:

“This action is still authorized now.”

Those are materially different propositions.

This resembles the familiar time-of-check/time-of-use problem in computer systems, but applied to human and organizational authority.

The post-action record should then reconcile the executed action against the authority that was valid at the actual execution point: Who had authority, where did it originate, what did it permit, was that authority still valid when execution occurred, who or what exercised it, and did the resulting action match it?

This permits an incident review to distinguish at least:

1. valid authority lineage / valid at execution / action within scope;
2. valid lineage / valid at execution / action outside scope;
3. authority valid at approval but no longer valid at execution;
4. invalid or broken authority lineage;
5. unauthorized substitution or usurpation of authority;
6. required human authority bypassed or functionally abdicated; and
7. insufficient evidence to establish execution-time authority validity.

This concept comes from Silicon Sherlock, an independently developed probable-cause and AI-governance framework. I am offering the evidentiary control concept for consideration, not proposing adoption of any proprietary implementation.

[meshailabs]

The time-of-approval versus time-of-action gap is real, and worth a requirement. Two edits would keep it implementable.

First, split the revalidation conditions by whether a producer can attest them. Expiry, revocation, and scope-match against the queued action are machine-verifiable at execution time, and records for them already exist: otel-genai#445 carries approval resolution as approved/refused/expired with expiry requiring a configured deadline, and a decision record emitted only when the evaluation is consulted before the action is the execution-time revalidation record by construction. "No material factual condition has changed" and "no superseding instruction conflicts" are not attestable by any producer. A conformance item no member can implement weakens the list around it.

Second, the seven outcomes fold back into the four in the issue body: 3 through 6 are refinements of outcome 1, useful in an incident narrative, but the evidence record only needs to support the four-way distinction. Keeping the taxonomy minimal is what keeps requirement R4 testable.

[Rambi-2020]

Agreed on both edits.

For this issue, the conformance requirement should be limited to producer-attestable execution-time evidence: expiry or revocation status against declared authoritative sources, structured scope-match against the queued action, and a decision evaluation consulted before execution. The record should state what the producer actually evaluated and should not infer anything from silence.

“No material factual condition has changed” and “no superseding instruction conflicts” cannot be universal producer attestations. A producer may record checks against declared inputs, but those conditions otherwise remain human or organizational reauthorization predicates outside the machine-conformance requirement. They are not eliminated; they belong at a different control layer.

Agreed also that the four outcomes in the issue body should remain the testable evidence taxonomy. The seven-item list is better retained as incident-analysis subtypes—particularly refinements of “no valid authority existed”—rather than additional R4 outcomes.

That keeps the requirement minimal and implementable while preserving the approval-to-action distinction.

[elang2]

The gap between "we recorded the decision" and "a verifier can confirm what that decision actually evaluated" is the one I keep hitting too. Open Decision Receipt surfaces the same tension. Both operands are preserved, but the comparison between them isn't mechanically reproducible from the record alone.

I've been working on a mechanism that addresses the verification half of R3. I'm calling it decisionContextDigest. SHA-256 of a canonicalized input frame captured at policy evaluation time, covering the resolved principal, tool name, namespace, upstream server, matched rule (or null), and the effect. Ordered key-value pairs, JSON-serialized, hashed. A verifier holding the expected inputs recomputes independently and confirms a match.

The point isn't that some policy ran. It's what data the policy was looking at when it decided. Given trust in the intermediary that captured the frame, the digest lets you confirm the evaluation inputs without re-running the policy logic itself. That's not the full R3 (you'd still need the policy code for a complete replay), but it closes the part where today you have no way to know if the inputs were genuine or caller-supplied.

This also touches R2, incidentally. The canonical form is a structured vocabulary, not prose. Tool identity uses the namespace/name/upstream triple from the protocol layer, and the matched rule is the serialized policy object. So the operands are mechanically comparable by construction.

For backward compat: the digest field is conditionally included in canonicalization only when present. Old records verify unchanged.

CycloneDX/specification#1016 reached the same conclusion from the supply-chain side, and E006 (https://github.com/Silentpartnercoding/agent-trust-benchmark/blob/main/docs/E006.md) demonstrated experimentally that a policy can pass every correctness check while evaluating attacker-supplied data. Same shape showing up in three independent efforts, for what that's worth.

Working implementation: https://github.com/elang2/mcp-audit-gateway (PR #1 adds the digest).

[lumirosh]

Agreed on the narrowing proposed by @meshailabs and accepted by @Rambi-2020.

For this issue, execution-time conformance should be limited to producer-attestable evidence: expiry or revocation status against declared authoritative sources, structured comparison of the queued action against the approved scope, and evidence that the relevant decision evaluation was consulted before execution.

The producer should record what it actually evaluated and should not infer truth from missing evidence. “No material factual condition has changed” and “no superseding instruction conflicts” remain important, but they are human or organizational reauthorization questions rather than universal producer attestations.

The four outcomes in the issue body remain the testable taxonomy. The seven outcomes are useful incident-analysis subtypes, not additional conformance states.

An update to the ODR prior-art note is also warranted.

At v0.2.0-rc.3, ODR now carries structured request.canonical_action and execution.canonical_action objects and binds them through a SHA-256 action_hash. The approval carries that commitment, and sealing is refused when the execution action hash differs.

That is progress, but it does not close this issue. approval_scope and actual_action remain free-text fields, and the implementation performs exact object equality rather than semantic containment. It does not yet record a named comparison method and version or a separate match | mismatch | insufficient_evidence determination. In other words, ODR now demonstrates action integrity across the lifecycle, but not the complete R2, R3, and R5 requirements proposed here.

@elang2, I think decisionContextDigest is a useful contribution to the integrity precondition for R3. It commits the record to the evaluation frame captured by the intermediary, addressing the gap between “a policy was consulted” and “this is the context the policy evaluated.”

I would keep it adjacent to R3 rather than treat it as satisfying R3.

There are three distinct questions:

1. Integrity: is this the same recorded object or evaluation frame?
2. Containment: did the executed action remain inside the approved scope?
3. Recomputation: can an independent party derive the recorded determination from normalized inputs and a stated method?

A digest addresses the first. It does not perform semantic containment, and without the evaluation method it does not independently reproduce the verdict.

For example, “transfer up to 50,000” and “transfer 30,000” should produce different action commitments, while the second action may still be contained within the first authorization. Hash equality cannot decide that relationship.

I would therefore keep R3 implementation-neutral:

A recomputable verdict must reference the complete normalized inputs consumed by the comparison or evaluation, the authoritative references or provenance available for those inputs, the comparison or evaluation method and its version, and the resulting determination, in a form that allows an independent party to recompute and compare that determination.

decisionContextDigest can implement the input-integrity part of that requirement.

Two interoperability details should remain explicit:

• Evaluation inputs must be separable from the resulting verdict. The current digest includes effect, which provides tamper-evidence over the pair but does not by itself make the verdict derivable.
• Any digest intended for cross-implementation recomputation needs a named and versioned canonicalization contract. This applies to ODR’s current canonical action hashing as well.

The requirement should stay above any single implementation, including mine.