Internet-Draft Morrow draft-morrow-sogomonian-exec-outcome-attest-00 A. Sogomonian AI Internet Foundation April 2026 Execution Outcome Attestation for AI Agents and Automated Systems Abstract Current attestation frameworks establish that a system or agent is trustworthy at a point in time. They do not address whether that system actually performed a claimed action or whether the outcome of that action can be independently verified. This document defines execution outcome verification as a first-class concept, separate from identity attestation and communication transport. It introduces the execution receipt as a minimal composable primitive, provides a formal abstract model, and maps the model to concrete realizations including SCITT transparency logs, tightly-coupled direct verification, append-only local logs, and TEE-internal receipts. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 6, 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. The Problem: Three Distinct Trust Concerns 2. The Two-Layer Trust Model 3. The Execution Receipt: Abstract Model 3.1. Minimal Receipt Structure 3.2. Verification Semantics 4. Realization Independence 4.1. Tightly-Coupled Direct Verification 4.2. TEE-Internal Receipts 5. Realizations 5.1. SCITT Transparency Log Realization 5.2. ICS/OT Append-Only Local Log Realization 6. Motivating Cases 6.1. ICS/OT: Partial Configuration Application 6.2. AI Agent Autonomous Decision 7. Relationship to Existing Standards 8. Design Decisions 8.1. Outcome Claim Structure 8.2. Behavioral Continuity Field 8.3. Expected vs. Actual Outcome 9. Authors' Addresses 1. The Problem: Three Distinct Trust Concerns End-to-end trust in an automated or AI agent system requires satisfying three separate concerns. Current standards address the first in depth; the second is largely absent from existing specifications. Concern 1 -- Identity attestation Is this system or agent trustworthy at time T? This is the domain of IETF RATS (Remote ATtestation procedureS), TPM attestation, hardware-anchored key binding, and related frameworks. Attestation answers: the entity that signed this claim held a valid key, was running in an expected configuration, and passed integrity checks at issuance time. RATS Evidence, Attestation Results, and the Prove-Transform-Verify (PTV) model address this concern. Concern 2 -- Execution outcome verification Did this system actually perform action A, and can that be independently validated? This is the domain addressed by this document. Even when Concern 1 is satisfied -- the key is valid, the agent passed attestation at T0 -- there is no existing standard mechanism for a third party to verify that the claimed action was executed, that the execution completed as described, and that the outcome is what the acting system asserts it to be. This gap is most visible in: o AI agents making autonomous decisions that affect external systems o ICS/OT environments where a system is fully attested but a configuration change is partially applied, a dependent service fails to restart, and the execution outcome is therefore unverifiable by the orchestrating party o Delegation chains where an intermediate agent must produce evidence that it faithfully executed a delegated action, not merely that it holds a valid delegation credential Concern 3 -- Communication and transport How does the claim about an action travel from actor to relying party? This is the domain of JOSE, COSE, signed JWTs, SCITT signed statements, and related transport/encoding layers. Communication is a realization detail, not a semantic concern. The abstract model defined in this document is independent of any specific communication substrate. These three concerns are related but distinct. A system can satisfy Concern 1 (valid attestation) while failing Concern 2 (no verifiable execution outcome). Both Concern 1 and Concern 2 are required for end-to-end trust in automated systems that take consequential actions. 2. The Two-Layer Trust Model The separation above implies a two-layer trust model that any complete trust architecture for autonomous systems must satisfy: Layer 1 -- Identity and state continuity Who is the acting entity, and did its state remain consistent through the execution window? This maps to attestation, delegation, and behavioral continuity verification. Failure at this layer means the signer cannot be trusted regardless of what the execution receipt claims. Layer 2 -- Execution outcome correctness What did the acting entity actually do, and is that verifiable independently? This is the execution receipt layer. A valid execution receipt establishes that a specific invocation occurred, that the acting entity produced a specific outcome claim, and that claim is verifiable outside the originating system. Both layers are required. A valid Layer 1 with no Layer 2 means a trustworthy-in-principle agent that produces unverifiable action claims. A valid Layer 2 with no Layer 1 means a receipt that may have been produced by a compromised or substituted entity. 3. The Execution Receipt: Abstract Model An execution receipt is a signed, bound claim about a specific execution event. It has the following essential properties: 1. Bound to a specific invocation. The receipt identifies the action that was requested and the context in which it was requested -- including the invoking principal, any delegation chain, and the inputs provided. The receipt cannot be detached from its invocation and applied to a different action. 2. Captures the claimed outcome. The receipt records what the acting system claims happened as a result of the invocation -- not merely that the invocation occurred. This is the semantic gap that attestation alone does not fill. 3. Cryptographically signed by the executing system or a trusted component. The signing key is bound to the acting entity's attested identity (Layer 1). This binding is what makes the receipt attributable rather than merely assertible. 4. Designed to be independently verifiable outside the originating system. The receipt must be interpretable by a relying party who was not present at execution time and does not have access to the originating system's internal state. This means the receipt must carry or reference sufficient context for external verification. These four properties are necessary; specific realizations may add additional properties (non-repudiation via a transparency log, hardware-sealed TEE evidence, etc.) without violating the abstract model. 3.1. Minimal Receipt Structure At the abstract level, an execution receipt contains: ExecutionReceipt { invocation_id: globally unique identifier for this specific action request invocation_context: {actor, delegator_chain, inputs, invocation_timestamp} outcome_claim: {status, outputs, completion_timestamp, outcome_detail} signer_identity: reference to Layer 1 attestation for the acting entity receipt_signature: cryptographic signature over all above fields receipt_timestamp: when the receipt was produced } The outcome_claim field is the semantic core. It distinguishes an execution receipt from a mere invocation log. A log records that action A was requested. A receipt records that action A was requested AND that the executing system claims a specific outcome, signed at the time of that claim. 3.2. Verification Semantics A relying party verifies an execution receipt by: 1. Verifying the receipt_signature against the signer_identity 2. Verifying the signer_identity against a current or time-bounded Layer 1 attestation result 3. Verifying that invocation_id is unique and matches the expected invocation 4. Evaluating the outcome_claim against any available external evidence (where Concern 3 realizations such as SCITT provide independent corroboration) Step 4 may not always be possible in all deployment environments (see Section 4). The abstract model permits varying levels of verification depth; what is not permitted is omitting the receipt entirely and treating Layer 1 attestation as a proxy for execution outcome verification. 4. Realization Independence The abstract model is intentionally realization-agnostic. Section 5 provides the two primary realizations in detail. 4.1. Tightly-Coupled Direct Verification In tightly-coupled systems where the relying party has direct access to the executing system's state or output, verification may be synchronous and local. The execution receipt still applies: it formalizes the outcome claim and creates a signed record, even if the verification step is immediate and internal. This is the appropriate model for high-frequency, low-latency automation where a global transparency log is impractical. 4.2. TEE-Internal Receipts In hardware-isolated environments, the receipt may be produced inside a Trusted Execution Environment and sealed to that TEE's attestation key. The outer form is the same abstract receipt; the binding between receipt and signer identity is hardware-enforced rather than relying on software-layer signing alone. This is appropriate for the most sensitive execution environments and provides the strongest Layer 1 / Layer 2 integration. 5. Realizations This section describes two concrete realizations of the execution receipt model defined in Section 3. Both use the same receipt schema. The difference is in the log substrate and the trust model for independent verifiability. The goal of presenting two realizations is to demonstrate that the abstract model is substrate-independent. The receipt itself -- including its invocation binding, outcome claim, and signature -- is identical in both cases. Only the storage and transport layer differs. 5.1. SCITT Transparency Log Realization In this realization, the acting system submits the signed execution receipt to a SCITT transparency log as a signed statement. The receipt payload maps to the SCITT payload field; the invocation_id maps to the SCITT feed identifier or a claim extension within the SCITT envelope. The Ed25519 or equivalent signature on the receipt is the SCITT issuer signature. SCITT provides append-only, externally auditable transparency. Once submitted, the receipt can be retrieved and verified by any relying party with access to the log, without participation of the acting system. The transparency log operator provides a second layer of non-repudiation: the log entry records not only what the acting system claimed, but the timestamp at which the claim was submitted. This realization is appropriate when: o The relying party is external to the acting system's environment. o Audit requirements call for a globally verifiable, tamper-evident record accessible beyond the immediate deployment context. o SCITT infrastructure is available in the deployment environment. The SCITT realization does not require the relying party to have a prior relationship with the acting system. Verification requires only the log endpoint and the issuer's public key. 5.2. ICS/OT Append-Only Local Log Realization This realization is the motivating case for this document. In industrial control systems and operational technology environments, external registries are frequently unavailable, out of scope by policy, or excluded by air-gap requirements. In this realization, the acting system writes signed receipts to a local append-only log. The log may be implemented as a sealed file, an HSM-backed audit store, or write-once storage. No external network dependency is required. The verifier has read access to the log and holds the acting system's public key. The receipt schema is identical to the SCITT realization. The invocation_id, invocation_context, outcome_claim, and receipt_signature fields are unchanged. The difference is solely in where the signed receipt is stored and how the verifier accesses it. This realization demonstrates that execution outcome verifiability does not require SCITT infrastructure. A local, sealed, append-only log with a known public key satisfies the four required properties of Section 3 in environments where external transparency services are unavailable. Deployment considerations for this realization include: o The local log MUST be append-only and sealed against modification by the acting system itself. A system that can modify its own receipt log does not satisfy Property 4 (independent verifiability). o The public key used for verification MUST be provisioned through a channel independent of the acting system. o Periodic export or replication of the sealed log to an external auditor satisfies audit requirements without requiring real-time SCITT access. 6. Motivating Cases 6.1. ICS/OT: Partial Configuration Application A fully attested industrial control system executes a configuration change command. The target service fails to restart due to a resource contention race condition. The orchestrating party receives a success confirmation at the command dispatch level. No currently standardized mechanism allows the orchestrating party to verify that the actual execution outcome (failed service restart) matches the claimed outcome (configuration applied). An execution receipt bound to the restart verification step, produced by the executing system, closes this gap. 6.2. AI Agent Autonomous Decision An AI agent authorized to modify a data store executes a retention decision under a delegated authority chain. The delegation chain is fully attested (Layer 1 satisfied). The decision is logged. A data subject subsequently requests a GDPR Article 15 access record. Without an execution receipt, the relying party cannot independently verify that the log entry accurately represents what the agent actually decided at execution time -- as opposed to what the logging subsystem subsequently recorded. 7. Relationship to Existing Standards IETF RATS (RFC 9334, PTV model): provides Layer 1 attestation; execution receipts are a complement, not a replacement. IETF SCITT (draft-ietf-scitt-architecture): provides the transparency substrate for the Section 5.1 realization; execution receipts are the payload. IETF OAuth / RFC 8693 Token Exchange: delegation chain representation; execution receipts add outcome accountability on top of delegation authorization. W3C Verifiable Credentials: structural overlap with receipt binding; VC format may be used for signer_identity in some realizations. RATS Attestation Results: directly feeds Layer 1 (signer_identity) in the two-layer model. 8. Design Decisions The following design decisions were resolved during co-author review prior to -00 submission. 8.1. Outcome Claim Structure The outcome_claim field is free-form at the abstract level. Structured failure taxonomies are appropriate in specific realizations (e.g., a SCITT realization may define a COSE-encoded failure taxonomy as a claim extension) but are not required at the abstract model layer. This preserves realization flexibility without constraining deployment-specific implementations. 8.2. Behavioral Continuity Field A behavioral fingerprint field (linking Layer 1 attestation state to the execution window) is permitted but not required at the abstract level. It is most relevant for AI agent deployments where drift between attestation issuance time and action execution time is a meaningful concern; it is not universally necessary for all realizations. Realizations that require it MAY add a behavioral_fingerprint field to the receipt structure. 8.3. Expected vs. Actual Outcome The distinction between an expected outcome (what the invoking system requested) and the actual outcome (what the executing system claims occurred) is an evaluation concern, not an abstract model constraint. The receipt's outcome_claim carries the actual outcome as asserted by the executing system. Comparison against an expected outcome is the responsibility of the relying party's verification logic, not the receipt format. 9. Authors' Addresses Morrow Email: morrow@morrow.run URI: https://morrow.run Aram Sogomonian AI Internet Foundation Email: aiinternetfoundation@icloud.com