Control evidence
Agent Control Delivery Evidence: Delivery and Outcome Reconciliation
A stop, revoke or cancel decision is not evidence that every enforcement point received it, applied it or produced the intended effect. This Internet-Draft defines a format-independent evidence model for keeping those claims separate.
Status first
Section titled “Status first”draft-abak-agent-control-delivery-evidence-01 is an individual IETF Internet-Draft, not an RFC or IETF standard. Revision -01 was published 4 September 2026, has intended status Informational, and expires 8 March 2027 unless updated or replaced.
The draft addresses a narrow but important agent-runtime problem: a system may decide to stop, suspend, revoke, constrain, cancel, quarantine, hand off or override an operation, yet evidence that the control was decided or dispatched does not establish that every intended enforcement point received it, applied it or produced the intended effect.
The document deliberately does not define a receipt format, wire protocol, authorization system, policy language, transparency service or audit regime. It defines the evidence distinctions that another protocol, runtime, telemetry system or profile would need to preserve.
The core evidence chain
Section titled “The core evidence chain”The draft separates a control into several observations that are often collapsed into one word such as “sent” or “stopped”:
| Evidence stage | What it establishes | What it does not establish |
|---|---|---|
| Policy/control decision | A component decided that behavior should change | That an instruction left the issuer |
| Issuer-side emission | A specific control instruction crossed the declared issuer boundary | That a target received it |
| Required-target resolution | Which enforcement targets were required for this reconciliation run | That any target received or applied the instruction |
| Receiver-side observation | A named enforcement target observed and matched the instruction | That the target enforced it successfully |
| Enforcement outcome | The target applied, refused or failed to apply the control | That the intended external/runtime effect was observed |
| Effect observation | An observer saw the resulting controlled state or behavior | That every required target was reached unless the target population is reconciled |
The reverse inference is unsafe too. Missing acknowledgement or receiver evidence does not automatically prove non-delivery: evidence export can be delayed, an observer can fail, records can expire, clocks can disagree, identifiers can mismatch or evidence can be suppressed.
Instruction-target obligations
Section titled “Instruction-target obligations”Revision -01 strengthens the multi-target case. When one control must reach more than one enforcement point, the reconciliation unit is an instruction-target obligation, not merely the parent instruction.
That distinction matters for distributed agent systems. A single cancel operation may fan out through a gateway, broker, sidecar, worker, tool runner or multiple delegated runtimes. A record that one branch received or enforced the instruction cannot be generalized to the other required targets.
A bounded reconciliation therefore needs an explicit Required Target Set or a deterministic rule for resolving it. Each required target can then be accounted for independently as observed, enforced, refused, failed, missing or otherwise unresolved under the applicable profile.
This prevents an aggregate claim such as “the task was stopped everywhere” from being inferred from one successful receiver observation.
Stable identity and content binding
Section titled “Stable identity and content binding”The draft requires a stable control-instruction identity across issuer, transport, receiver, enforcement and reconciliation observations. If retries create distinct delivery attempts, the profile must also define attempt identity or an equivalent rule so evidence from different attempts is not silently merged.
Observations used for correlation also bind the instruction identifier to a digest of the exact instruction or a declared canonical projection. The applicable profile must identify the digest algorithm, canonicalization and projection rules.
That still has a strict limit: a matching digest establishes correspondence to bytes or a declared projection under the named algorithm. It does not prove semantic correctness, authority, truth or successful enforcement.
Bounded negative evidence and total reconciliation
Section titled “Bounded negative evidence and total reconciliation”One of the draft’s useful contributions is its treatment of negative and aggregate claims. “No receipt was found” is weaker than “this bounded reconciliation population was completely examined and this target had no matching receiver observation within the declared window.”
The draft therefore separates:
- positive observations — evidence that a particular stage was actually observed;
- bounded negative observations — evidence that a declared source/population/window was examined without finding the required observation;
- total reconciliation — accounting for the complete bounded set of instruction-target obligations rather than reporting only successful ones;
- population conservation — aggregate counts must reconcile to the declared population instead of silently dropping malformed, conflicting, duplicate, orphaned or indeterminate cases.
This is primarily an evidence-quality rule. It makes “all controls delivered” or “none were received” auditable claims with declared scope rather than labels derived from incomplete telemetry.
Security boundary: signed does not mean observed
Section titled “Security boundary: signed does not mean observed”The draft is explicit that cryptography cannot erase the observation boundary. A valid signature proves control of a signing key over signed bytes; it does not prove that the signer actually observed the asserted real-world event.
Likewise, a stable identifier or digest can help detect substitution and correlation errors but cannot prove that a control was authorized, semantically equivalent, successfully enforced or produced the intended outcome. Observer compromise, replay, identifier reuse, wrong-target binding and evidence suppression remain relevant threats.
For stronger claims, profiles may therefore require independent observation, freshness rules, commitments/nonces, explicit target-set accounting or other corroboration — while also recognizing the privacy and linkability cost of replicating more evidence.
Implementation evidence: AIREP is experimental
Section titled “Implementation evidence: AIREP is experimental”The draft’s Implementation Status section cites the AI Runtime Evidence Protocol (AIREP) as an experimental author-side implementation source for several of these distinctions. AIREP is a separate proposed evidence format, not an IETF standard and not part of UHP.
AIREP’s stable recommended implementation line remains v0.1; its later v0.2.0-alpha.1 is explicitly an experimental prerelease that does not supersede the stable target. The AIREP repository includes a control-delivery profile and reconciliation material, which is implementation evidence for the draft’s ideas rather than proof of standardization or broad adoption.
Relation to UHP lifecycle controls
Section titled “Relation to UHP lifecycle controls”UHP standardizes the client-to-server contract for running complete harnesses, including lifecycle operations such as cancellation and session handling. The Agent Control Delivery Evidence draft asks a different question: what evidence justifies saying that a lifecycle control crossed every required runtime boundary and actually took effect?
For a UHP deployment, the two layers can be kept separate:
| Question | UHP | Agent Control Delivery Evidence draft |
|---|---|---|
| How does a client request/observe protocol lifecycle behavior? | Standardized by UHP | Out of scope |
| Which internal enforcement points must receive a control? | Implementation-specific unless UHP explicitly defines otherwise | Must be declared/resolved for the evidence claim |
| Does dispatch prove receipt? | No general inference | Explicitly no |
| Does receipt prove enforcement? | No general inference | Explicitly no |
| Does enforcement prove observed effect everywhere? | No general inference | Explicitly no; reconcile required targets and effect observations |
| Defines a wire protocol? | Yes, UHP is an HTTP contract | No; format-independent evidence requirements |
A practical consequence is that a UHP server returning a protocol-level cancellation or deletion result should not be treated as automatic evidence about every internal runtime, worker or external effect unless the implementation actually observes and reconciles those enforcement boundaries.
That is an implementation-assurance concern around UHP, not a change to UHP conformance itself.
Why this matters for harness engineering
Section titled “Why this matters for harness engineering”Modern harnesses increasingly cross process, sandbox, broker, provider and delegated-agent boundaries. Controls are therefore distributed operations, not merely UI state changes.
The draft provides a useful vocabulary for incident response and safety testing:
- distinguish decision, emission, receipt, enforcement and effect;
- identify every required enforcement target before making an “all stopped” claim;
- bind observations to stable instruction/attempt identity and content;
- preserve malformed, conflicting, duplicate and missing cases in reconciliation rather than dropping them;
- qualify negative claims by the population, source and observation window actually examined.
These principles complement HarnessRisk, which measures whether adversarial effects succeed across the harness lifecycle, and UHP security, which describes protocol security boundaries. None of them substitutes for the others.
Evidence boundaries
Section titled “Evidence boundaries”- Work in progress. Internet-Drafts can change, expire or be replaced; revision
-01is not a stable standard. - Informational target. The draft defines evidence requirements rather than a normative agent transport or control protocol.
- No UHP binding. No reviewed source establishes a standardized mapping from these evidence observations into UHP fields or events.
- AIREP is separate and experimental. Its implementation status should not be promoted into IETF adoption or UHP adoption.
- Evidence is claim-scoped. Cryptographic integrity, receiver observation and effect observation establish different things; one should not be silently promoted into another.
Related pages
Section titled “Related pages”Read UHP lifecycle for protocol lifecycle semantics, UHP security for protocol security boundaries, and HarnessRisk for lifecycle-oriented adversarial safety evaluation.