Cryptographic Execution-Trace Verification, JCS Canonicalization, and Fail-Closed Delegation Attestation for Autonomous AI Agents

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 2 May 2027.¶

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. Introduction

Autonomous AI agents increasingly invoke external tools, modify enterprise state, and delegate subtasks across multi-agent boundaries using protocols such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) transport envelopes. Without a deterministic, cryptographically verifiable execution receipt, a relying party cannot distinguish between a self-reported agent log and an independently verifiable commitment record.¶

This specification formalizes the fail-closed verification invariants implemented in the open-source AgentTrust ("agentrust-io/trace-spec", "agentrust-io/agent-manifest", and "agentrust-io/weight-custody-manifest") conformance suites and empirically evaluated in [TR-2026-01], [TR-2026-02], and [TR-2026-03].¶

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Deterministic Pre-Image Canonicalization (RFC 8785 JCS)

To prevent cross-language signature verification drift between Python, TypeScript/JavaScript, and Rust verifiers, every execution trace envelope MUST be serialized according to the JSON Canonicalization Scheme [RFC8785] prior to digest calculation or signature verification:¶

• Non-string dictionary keys MUST be rejected with a deterministic type error rather than silently coerced.¶
• Lone UTF-16 surrogates (U+D800 through U+DFFF) and non-finite IEEE 754 floating-point values (NaN, +Infinity, -Infinity) MUST cause canonicalization to fail closed.¶
• Duplicate JSON object member names within signed payloads MUST be rejected during parsing before signature appraisal.¶

4. Strict Base64url and JWK Public-Key Hygiene

Verifiers evaluating detached signatures, witness receipts, or JWK bundles [RFC7517] MUST enforce canonical unpadded base64url encoding (Section 5 of [RFC4648]):¶

• Padding characters ("="), non-alphabet whitespace, or non-zero trailing pad bits MUST be rejected.¶
• Verification bundles MUST NOT contain private JWK parameters ("d", "p", "q", "dp", "dq", "qi", "oth"). Any trust bundle containing a private key parameter MUST be rejected immediately.¶
• JWK thumbprints [RFC7638] and confirmation claims ("cnf.jwk") MUST be validated against the pinned trust store prior to revocation list evaluation.¶

5. Parent-Linked Delegation Chain Verification

When an orchestrator agent delegates authority to a sub-agent, each hop record MUST include a "parent_record_hash" field containing the lowercase hexadecimal SHA-256 digest of the canonicalized parent record. A verifier evaluating an N-hop delegation chain MUST verify:¶

1. Cryptographic signature validity of every hop i in 0..N-1.¶
2. Hash continuity: hop[i].parent_record_hash == SHA256(JCS(hop[i-1])).¶
3. Scope attenuation: hop[i].granted_scopes is a strict subset of or equal to hop[i-1].granted_scopes.¶
4. Temporal monotonicity: hop[i].issued_at >= hop[i-1].issued_at and hop[i].expires_at <= hop[i-1].expires_at.¶

6. Security Considerations

Verifiers that accept boolean literals as integer timestamps (for example, in runtimes where boolean is a subclass of integer) or that silently truncate recursive argument walks without flagging depth exhaustion introduce fail-open bypass vectors. Implementations MUST validate exact integer types for sequence numbers, epochs, and clock-skew bounds, and MUST fail closed when structural nesting bounds are exceeded.¶

7. IANA Considerations

This document has no IANA actions.¶

Author's Address