



SPICE                                                        R. Krishnan
Internet-Draft                                       JPMorgan Chase & Co
Intended status: Informational                                 A. Prasad
Expires: 19 September 2026                                        Oracle
                                                                D. Lopez
                                                              Telefonica
                                                            S. Addepalli
                                                                  Aryaka
                                                           18 March 2026


     Cryptographically Verifiable Intent Chain for AI Agent Content
                               Provenance
                     draft-mw-spice-intent-chain-00

Abstract

   This document defines the intent_chain claim as a companion to the
   actor_chain claim defined in {{!I-D.draft-mw-spice-actor-chain}}.
   While the actor chain addresses delegation provenance (WHO delegated
   to whom), the intent chain addresses content provenance (WHAT was
   produced and HOW it was transformed).

   In AI agent workflows, content flows through multiple processing
   stages including AI agents and filters.  The intent chain provides a
   cryptographically verifiable, tamper-evident record of this content
   journey.  The full intent chain is stored as ordered logs, with only
   the Merkle root included in the OAuth token for efficiency.

   Together, the actor chain and intent chain provide complete
   governance for autonomous AI agent systems, addressing Spoofing,
   Tampering, Repudiation, and Elevation of Privilege threats in the
   STRIDE threat model.

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



Krishnan, et al.        Expires 19 September 2026               [Page 1]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   This Internet-Draft will expire on 19 September 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.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  The Problem: Content Provenance Gap . . . . . . . . . . .   4
     1.2.  Relationship to Actor Chain and Inference Chain . . . . .   5
     1.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   6
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Three-Layer Governance Model  . . . . . . . . . . . . . .   7
     3.2.  Session as Root of Trust  . . . . . . . . . . . . . . . .   7
     3.3.  Actor Chain (WHO) - Reference . . . . . . . . . . . . . .   8
     3.4.  Intent Chain (WHAT) - This Document . . . . . . . . . . .   8
     3.5.  STRIDE Threat Model Coverage  . . . . . . . . . . . . . .   8
   4.  Intent Chain Definition . . . . . . . . . . . . . . . . . . .   9
     4.1.  Entry Types . . . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  Non-Deterministic Entries . . . . . . . . . . . . . . . .  10
     4.3.  Deterministic Entries . . . . . . . . . . . . . . . . . .  11
     4.4.  Entry Structure . . . . . . . . . . . . . . . . . . . . .  12
       4.4.1.  intent_digest Computation . . . . . . . . . . . . . .  12
   5.  Storage Architecture  . . . . . . . . . . . . . . . . . . . .  13
     5.1.  Intent Registry (Ordered Logs)  . . . . . . . . . . . . .  13
       5.1.1.  Relationship Between session_id and jti . . . . . . .  14
     5.2.  Merkle Tree Construction  . . . . . . . . . . . . . . . .  15
     5.3.  Merkle Root in Token  . . . . . . . . . . . . . . . . . .  15
   6.  Token Structure . . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  Combined Token Format . . . . . . . . . . . . . . . . . .  16
     6.2.  Claim Definitions . . . . . . . . . . . . . . . . . . . .  17
       6.2.1.  Session Claims  . . . . . . . . . . . . . . . . . . .  17
       6.2.2.  Actor Chain Claims  . . . . . . . . . . . . . . . . .  18
       6.2.3.  Intent Chain Claims . . . . . . . . . . . . . . . . .  18
     6.3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  18
       6.3.1.  Minimal Token (Actor Chain Only)  . . . . . . . . . .  18



Krishnan, et al.        Expires 19 September 2026               [Page 2]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


       6.3.2.  Minimal Token (Intent Chain Only) . . . . . . . . . .  19
       6.3.3.  Full Token (Both Chains)  . . . . . . . . . . . . . .  19
   7.  Verification Procedures . . . . . . . . . . . . . . . . . . .  19
     7.1.  Request-Time Policy Checks  . . . . . . . . . . . . . . .  19
     7.2.  Forensic Verification . . . . . . . . . . . . . . . . . .  20
       7.2.1.  Token Archival  . . . . . . . . . . . . . . . . . . .  20
       7.2.2.  Full Chain Verification . . . . . . . . . . . . . . .  21
       7.2.3.  Cross-Chain Correlation . . . . . . . . . . . . . . .  21
       7.2.4.  Dispute Resolution Workflow . . . . . . . . . . . . .  22
       7.2.5.  Single Entry Verification (Merkle Proof)  . . . . . .  22
   8.  Operational Flows . . . . . . . . . . . . . . . . . . . . . .  23
     8.1.  Intent Chain Construction . . . . . . . . . . . . . . . .  23
     8.2.  Token Exchange Integration  . . . . . . . . . . . . . . .  24
     8.3.  Request-Time Check at Relying Party . . . . . . . . . . .  25
   9.  Policy Enforcement  . . . . . . . . . . . . . . . . . . . . .  26
     9.1.  Policy Examples . . . . . . . . . . . . . . . . . . . . .  26
       9.1.1.  Require All Outputs Filtered  . . . . . . . . . . . .  26
       9.1.2.  Require Non-Deterministic Filter for AI Outputs . . .  27
       9.1.3.  Verify Specific Transformation Applied  . . . . . . .  27
     9.2.  Integration with Policy Engines . . . . . . . . . . . . .  27
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  28
     10.1.  STRIDE Analysis  . . . . . . . . . . . . . . . . . . . .  28
     10.2.  Signing Requirements by Entry Type . . . . . . . . . . .  28
     10.3.  Replay Protection  . . . . . . . . . . . . . . . . . . .  29
     10.4.  Chain Integrity  . . . . . . . . . . . . . . . . . . . .  29
     10.5.  Credential Isolation . . . . . . . . . . . . . . . . . .  29
   11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  29
     11.1.  Selective Disclosure . . . . . . . . . . . . . . . . . .  29
     11.2.  Content Hash vs Content Storage  . . . . . . . . . . . .  30
   12. Implementation Guidance . . . . . . . . . . . . . . . . . . .  30
     12.1.  Intent Registry Implementation . . . . . . . . . . . . .  30
     12.2.  Multi-AS Deployments . . . . . . . . . . . . . . . . . .  31
     12.3.  Scalability Considerations . . . . . . . . . . . . . . .  31
     12.4.  Operational Recommendations  . . . . . . . . . . . . . .  31
     12.5.  Registry Availability  . . . . . . . . . . . . . . . . .  32
   13. Design Rationale: Merkle Root in Token  . . . . . . . . . . .  32
   14. Audit Procedures  . . . . . . . . . . . . . . . . . . . . . .  33
     14.1.  Cross-Chain Binding  . . . . . . . . . . . . . . . . . .  33
   15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
     15.1.  JWT Claim Registration . . . . . . . . . . . . . . . . .  34
     15.2.  CWT Claim Registration . . . . . . . . . . . . . . . . .  34
   Appendix A.  Merkle Tree Construction Details . . . . . . . . . .  35
     A.1.  Tree Structure  . . . . . . . . . . . . . . . . . . . . .  35
     A.2.  Reference Construction Algorithm  . . . . . . . . . . . .  36
   Appendix B.  Complete Token Examples  . . . . . . . . . . . . . .  36
     B.1.  Full Governance Token . . . . . . . . . . . . . . . . . .  36
     B.2.  Corresponding Intent Chain Log Entries  . . . . . . . . .  37
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  39



Krishnan, et al.        Expires 19 September 2026               [Page 3]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


1.  Introduction

1.1.  The Problem: Content Provenance Gap

   The Actor Chain extension to {{!RFC8693}} (defined in {{!I-D.draft-
   mw-spice-actor-chain}}) addresses the Delegation Auditability Gap by
   providing cryptographic proof of the actual delegation path between
   AI agents.  However, it does not address a complementary gap:
   *Content Provenance*.

   In AI agent workflows, content flows through multiple processing
   stages:

   Agent A -> Filter -> Filter -> Agent B -> Filter -> Agent C -> Tool

   Each stage may transform the content.  AI agent outputs are
   inherently non-deterministic and cannot be trusted without
   validation.  Filters (both AI-based and rule-based) transform this
   content before it reaches the next stage.

   For complete governance, systems require proof of:

   *  *What* each AI agent originally produced (raw output)
   *  *How* each filter transformed the content
   *  *Whether* transformations were deterministic (reproducible) or
      non-deterministic (AI-based)
   *  *The complete chain* of content transformations within a session

   Without this proof, the content transformation history cannot be
   reconstructed for audit or dispute resolution.  Consider the
   following repudiation scenario:

   1.  Agent A produces a response containing a harmful instruction
       (e.g., caused by prompt injection).
   2.  The response passes through an AI guardrail filter, which fails
       to catch the harmful content.
   3.  Agent B acts on the harmful instruction, causing damage.
   4.  During investigation, Agent A's operator claims "Agent A never
       produced that output — it must have been injected by a downstream
       filter."

   Without cryptographic proof binding Agent A's identity to its
   specific output hash, this claim cannot be disproven.  The intent
   chain solves this by requiring every agent to sign input_hash +
   output_hash via intent_sig, creating non-repudiable evidence of what
   each agent received and produced.





Krishnan, et al.        Expires 19 September 2026               [Page 4]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


1.2.  Relationship to Actor Chain and Inference Chain

   This specification is part of a three-axis "Truth Stack" for AI agent
   governance:

   +===================+=============+==============+==================+
   | Specification     | Axis        | Question     | STRIDE Coverage  |
   |                   |             | Answered     |                  |
   +===================+=============+==============+==================+
   | *Actor Chain*     | Identity    | WHO          | Spoofing,        |
   | ({{!I-D.draft-    |             | delegated to | Repudiation,     |
   | mw-spice-actor-   |             | whom?        | Elevation of     |
   | chain}})          |             |              | Privilege        |
   +-------------------+-------------+--------------+------------------+
   | *Intent Chain*    | Content     | WHAT was     | Repudiation,     |
   | (this document)   |             | produced and | Tampering        |
   |                   |             | transformed? |                  |
   +-------------------+-------------+--------------+------------------+
   | *Inference        | Computation | HOW was the  | Spoofing         |
   | Chain* ({{!I-     |             | output       | (computational), |
   | D.draft-mw-       |             | computed?    | Tampering        |
   | spice-inference-  |             |              | (model)          |
   | chain}})          |             |              |                  |
   +-------------------+-------------+--------------+------------------+

                                  Table 1

    +=============+=======+============+==========+==================+
    | Chain       | Plane | Token      | Full     | Primary Consumer |
    |             |       | Content    | Chain    |                  |
    +=============+=======+============+==========+==================+
    | *Actor*     | Data  | Full chain | In token | Every Relying    |
    |             | Plane | inline     |          | Party (real-time |
    |             |       |            |          | authorization)   |
    +-------------+-------+------------+----------+------------------+
    | *Intent*    | Audit | Merkle     | External | Audit systems,   |
    |             | Plane | root only  | registry | forensic         |
    |             |       |            |          | investigators    |
    +-------------+-------+------------+----------+------------------+
    | *Inference* | Audit | Merkle     | External | Auditors,        |
    |             | Plane | root only  | registry | compliance       |
    |             |       |            |          | systems          |
    +-------------+-------+------------+----------+------------------+

                                 Table 2

   The three chains are independent and composable:




Krishnan, et al.        Expires 19 September 2026               [Page 5]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   *  *Actor Chain Only*: Real-time authorization, access control
   *  *Intent Chain Only*: Content audit, debugging, filter validation
   *  *Inference Chain Only*: Computational integrity verification for
      single-agent systems
   *  *Actor + Intent*: Full content governance, dispute resolution,
      regulatory compliance
   *  *All Three*: Complete "Truth Stack" — identity, content, and
      computational provenance

1.3.  Design Goals

   The intent chain is designed with the following goals:

   1.  *Content Provenance*: Cryptographic proof of what each agent
       produced
   2.  *Transformation Tracking*: Record of how filters modified content
   3.  *Tamper Evidence*: Merkle tree structure prevents undetected
       modification
   4.  *Efficiency*: Only Merkle root in token; full chain in logs
   5.  *Scalability*: Append-only logs scale horizontally
   6.  *Modularity*: Usable independently or with actor chain
   7.  *Standards Alignment*: Compatible with OAuth 2.0, JWT, SPIFFE

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

   Intent Chain:  An ordered sequence of Intent Chain Entries
      representing the complete content journey from originating agent
      through filters to final output within a session.
   Intent Chain Entry:  A record identifying a single content
      transformation, including the agent identity, entry type, content
      hashes, and cryptographic signature.
   AI Agent:  An autonomous decision-maker that produces content and can
      delegate authority.  AI agents appear in both the actor chain (for
      delegation) and the intent chain (for output provenance).
   Non-Deterministic Filter:  A processor (typically AI-based) whose
      output cannot be reproduced from its input.  Examples include AI
      guardrails, LLM-based content rewriters, and semantic classifiers.
      Both input and output MUST be signed.
   Deterministic Filter:  A processor whose output can be reproduced
      from its input and rules.  Examples include schema validators,
      regex sanitizers, and bounds checkers.  Output can be re-derived
      for verification.



Krishnan, et al.        Expires 19 September 2026               [Page 6]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   Intent Root:  The Merkle root hash of the complete intent chain,
      included in the OAuth token.
   Intent Registry:  An append-only ordered log storing the full intent
      chain entries, partitioned by session.
   Actor Chain Registry:  The append-only ordered log storing the full
      per-actor signature evidence for the actor chain, as defined in
      {{!I-D.draft-mw-spice-actor-chain}}. Referenced by the
      actor_chain_registry claim in the token.

3.  Architecture Overview

3.1.  Three-Layer Governance Model

   The governance model consists of three layers:

   *  *Session*: Root of trust and lifecycle management.  Initiated by
      human approval or system authorization.  Contains subject, expiry,
      and approval reference.
   *  *Actor Chain (WHO)*: Contains AI agents only.  Full chain stored
      in token.  Addresses Spoofing, Repudiation, and Elevation of
      Privilege.  Defined in {{!I-D.draft-mw-spice-actor-chain}}.
   *  *Intent Chain (WHAT)*: Contains AI agents and filters.  Full chain
      stored in ordered logs; Merkle root in token.  Addresses
      Repudiation and Tampering.  Defined in this document.
   *  *Inference Chain (HOW)*: Contains per-inference computational
      proofs.  Full proofs stored in ordered logs; Merkle root in token.
      Addresses Computational Spoofing and Model Tampering.  Defined in
      {{!I-D.draft-mw-spice-inference-chain}}.

3.2.  Session as Root of Trust

   Every governance chain traces back to a session.  The session
   provides:

   *  *Origin*: Who or what initiated the workflow
   *  *Lifecycle*: When the session expires
   *  *Revocation Point*: Revoking session invalidates all activity
   *  *Audit Boundary*: Session defines the unit of audit

   Session information is captured in standard OAuth token claims:











Krishnan, et al.        Expires 19 September 2026               [Page 7]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   +=======+===========================================================+
   | Claim | Purpose                                                   |
   +=======+===========================================================+
   | sub   | Session subject (human or system initiator)               |
   +-------+-----------------------------------------------------------+
   | sid   | Session identifier — stable across token                  |
   |       | exchanges within a session.  Equals                       |
   |       | session.session_id.  Defined as a top-level               |
   |       | claim in {{!I-D.draft-mw-spice-actor-chain}}              |
   +-------+-----------------------------------------------------------+
   | jti   | Token identifier (unique per token exchange)              |
   +-------+-----------------------------------------------------------+
   | iat   | Session start time                                        |
   +-------+-----------------------------------------------------------+
   | exp   | Session expiry time                                       |
   +-------+-----------------------------------------------------------+

                                  Table 3

3.3.  Actor Chain (WHO) - Reference

   The actor chain is defined in {{!I-D.draft-mw-spice-actor-chain}}.
   Key properties:

   *  Contains AI agents only (autonomous decision-makers)
   *  Tracks delegation of authority
   *  Full chain included in token
   *  Addresses Spoofing, Repudiation, Elevation of Privilege

   This document assumes familiarity with the actor chain specification.

3.4.  Intent Chain (WHAT) - This Document

   The intent chain is defined in this document.  Key properties:

   *  Contains AI agents AND filters
   *  Tracks content production and transformation
   *  Merkle root in token; full chain in ordered logs
   *  Addresses Repudiation and Tampering

3.5.  STRIDE Threat Model Coverage

    +===================+===========================+================+
    | Threat            | Mitigation                | Component      |
    +===================+===========================+================+
    | *S* - Spoofing    | Cryptographic identity,   | Actor Chain    |
    |                   | signed chain entries      |                |
    +-------------------+---------------------------+----------------+



Krishnan, et al.        Expires 19 September 2026               [Page 8]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


    | *T* - Tampering   | Merkle tree integrity,    | Intent Chain   |
    |                   | append-only logs          |                |
    +-------------------+---------------------------+----------------+
    | *R* - Repudiation | Signed delegation (Actor) | Both           |
    |                   | + Signed outputs (Intent) |                |
    +-------------------+---------------------------+----------------+
    | *I* - Information | Selective disclosure (SD- | Both           |
    | Disclosure        | JWT)                      | (optional)     |
    +-------------------+---------------------------+----------------+
    | *D* - Denial of   | Session expiry, rate      | Session +      |
    | Service           | limits                    | Infrastructure |
    +-------------------+---------------------------+----------------+
    | *E* - Elevation   | Scope attenuation, policy | Actor Chain    |
    | of Privilege      | enforcement               |                |
    +-------------------+---------------------------+----------------+

                                 Table 4

4.  Intent Chain Definition

4.1.  Entry Types

   The intent chain contains two types of entries:

    +===================+===================+===========+=============+
    | Entry Type        | Determinism       |Signed     |Type-Specific|
    |                   |                   |Fields     |Fields       |
    +===================+===================+===========+=============+
    | Non-Deterministic | Non-deterministic |input_hash |model_info   |
    | (AI agent output, |                   |+          |(optional)   |
    | AI-based filter)  |                   |output_hash|             |
    +-------------------+-------------------+-----------+-------------+
    | Deterministic     | Deterministic     |input_hash |rule_id,     |
    | (rule-based       |                   |+          |rule_hash    |
    | filter)           |                   |output_hash|             |
    +-------------------+-------------------+-----------+-------------+

                                  Table 5

   All entry types REQUIRE both input_hash and output_hash.  This
   uniform structure ensures that every consecutive pair satisfies
   entry[i].output_hash == entry[i+1].input_hash, creating a complete
   content provenance chain.  The cost is approximately 40 bytes per
   entry in the ordered logs — not in the token itself, which carries
   only the Merkle root regardless of entry count.






Krishnan, et al.        Expires 19 September 2026               [Page 9]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


4.2.  Non-Deterministic Entries

   Non-deterministic entries record outputs from AI agents or AI-based
   filters whose output cannot be reproduced from the input alone.

   *Examples*:

   *  AI agent outputs (orchestrator, planner, tool agent)
   *  AI guardrails (Llama Guard, NeMo Guardrails)
   *  LLM-based content rewriters
   *  Semantic classifiers

   *Properties*:

   *  Sub is an AI agent or AI-based filter (agents also appear in actor
      chain)
   *  Output is non-deterministic (cannot be reproduced)
   *  input_hash and output_hash MUST be recorded and signed

   *Agent Output Example*:

   {
     "type": "non_deterministic",
     "sub": "spiffe://example.com/agent/orchestrator",
     "input_hash": "sha256:fff000...",
     "output_hash": "sha256:abc123...",
     "iat": 1700000010,
     "intent_digest": "sha256:...",
     "intent_sig": "eyJhbGci..."
   }

   *AI Filter Example*:

   {
     "type": "non_deterministic",
     "sub": "spiffe://example.com/filter/ai-guardrail",
     "filter_version": "v2.1",
     "input_hash": "sha256:abc123...",
     "output_hash": "sha256:def456...",
     "model_info": {
       "model": "llama-guard-3",
       "categories": ["violence", "pii", "prompt_injection"]
     },
     "iat": 1700000015,
     "intent_digest": "sha256:...",
     "intent_sig": "eyJhbGci..."
   }




Krishnan, et al.        Expires 19 September 2026              [Page 10]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


4.3.  Deterministic Entries

   Deterministic filter entries record transformations by rule-based
   filters whose output can be reproduced from the input and rules.

   *Examples*:

   *  Schema validators (JSON Schema)
   *  Regex sanitizers (XSS removal)
   *  Bounds checkers (amount limits)
   *  PII redactors (pattern-based)

   *Properties*:

   *  Sub is a rule-based filter
   *  Output CAN be reproduced from input + rules
   *  input_hash and output_hash MUST be recorded and signed
   *  rule_id and rule_hash are type-specific signed fields in the log
      entry, enabling independent re-verification
   *  Output can be re-derived by re-applying the rule to the input

   *Structure*:

   {
     "type": "deterministic",
     "sub": "spiffe://example.com/filter/schema-validator",
     "filter_version": "v1.0",
     "input_hash": "sha256:def456...",
     "output_hash": "sha256:ghi789...",
     "rule_id": "ticket-schema-v2",
     "rule_hash": "sha256:rrr...",
     "transform_applied": {
       "fields_validated": ["title", "priority", "amount"],
       "fields_modified": ["priority"],
       "modification": {
         "priority": {
           "from": "critical",
           "to": "medium",
           "reason": "bounds_exceeded"
         }
       }
     },
     "reproducible": true,
     "iat": 1700000016,
     "intent_digest": "sha256:...",
     "intent_sig": "eyJhbGci..."
   }




Krishnan, et al.        Expires 19 September 2026              [Page 11]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


4.4.  Entry Structure

   All intent chain entries share common fields:

   +===============+========+==========+==============================+
   | Field         | Type   | Required | Description                  |
   +===============+========+==========+==============================+
   | type          | string | REQUIRED | Entry type:                  |
   |               |        |          | non_deterministic,           |
   |               |        |          | deterministic                |
   +---------------+--------+----------+------------------------------+
   | sub           | string | REQUIRED | SPIFFE ID of the agent or    |
   |               |        |          | filter                       |
   +---------------+--------+----------+------------------------------+
   | input_hash    | string | REQUIRED | SHA-256 hash of the input    |
   |               |        |          | content                      |
   +---------------+--------+----------+------------------------------+
   | output_hash   | string | REQUIRED | SHA-256 hash of the output   |
   |               |        |          | content                      |
   +---------------+--------+----------+------------------------------+
   | iat           | number | REQUIRED | Timestamp when entry was     |
   |               |        |          | created                      |
   +---------------+--------+----------+------------------------------+
   | intent_digest | string | REQUIRED | Hash of the canonically      |
   |               |        |          | serialized entry for Merkle  |
   |               |        |          | leaf computation             |
   +---------------+--------+----------+------------------------------+
   | intent_sig    | string | REQUIRED | Signature over intent_digest |
   |               |        |          | using the agent's or         |
   |               |        |          | filter's private key         |
   +---------------+--------+----------+------------------------------+

                                 Table 6

4.4.1.  intent_digest Computation

   The intent_digest field is computed as the SHA-256 hash of the
   canonically serialized entry, excluding the intent_digest and
   intent_sig fields themselves.  This hash serves as the leaf node in
   the Merkle tree.

   For an entry E with fields {type, sub, input_hash, output_hash, iat,
   ...}:

intent_digest = SHA-256(canonical_json(E \ {intent_digest, intent_sig}))

   Where canonical_json follows JSON Canonicalization Scheme {{JCS}}
   (RFC 8785) to ensure deterministic serialization.



Krishnan, et al.        Expires 19 September 2026              [Page 12]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   The intent_sig (when REQUIRED) is computed over the intent_digest
   value using the agent's private key:

   intent_sig = Sign(agent_key, intent_digest)

   This two-step process ensures that: (a) the digest is stable and
   independent of signature ordering, and (b) the signature covers all
   content-relevant fields of the entry.

   Additional fields by entry type:

      +===================+===================+====================+
      | Field             | Entry Types       | Description        |
      +===================+===================+====================+
      | filter_version    | Filters           | Version of filter  |
      +-------------------+-------------------+--------------------+
      | rule_id           | Deterministic     | Identifier of rule |
      |                   |                   | applied            |
      +-------------------+-------------------+--------------------+
      | rule_hash         | Deterministic     | Hash of rule       |
      |                   |                   | definition         |
      +-------------------+-------------------+--------------------+
      | model_info        | Non-deterministic | AI model           |
      |                   |                   | information        |
      +-------------------+-------------------+--------------------+
      | transform_applied | Filters           | Details of         |
      |                   |                   | transformation     |
      +-------------------+-------------------+--------------------+
      | reproducible      | Deterministic     | Boolean indicating |
      |                   |                   | reproducibility    |
      +-------------------+-------------------+--------------------+

                                 Table 7

5.  Storage Architecture

5.1.  Intent Registry (Ordered Logs)

   The intent registry stores immutable intent chain entries as ordered
   logs.

   *Contents*:

   *  Non-deterministic entries (AI agent outputs, AI-based filters)
   *  Deterministic entries (rule-based filters)






Krishnan, et al.        Expires 19 September 2026              [Page 13]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   |  Intent registry entries MUST NOT contain OAuth tokens, bearer
   |  credentials, or signing keys.  Entries contain only content
   |  hashes, metadata, agent identities, and entry-level signatures.
   |  The token references the registry via the intent_registry claim;
   |  the registry MUST NOT store or reference the token itself.

   *Properties*:

   *  Append-only (immutable)
   *  Ordered by offset within session
   *  Partitioned by session.session_id
   *  Eventual consistency acceptable

   Implementations SHOULD use an append-only log that supports
   partitioned, ordered retrieval by the token's session.session_id
   claim and provides tamper-evident guarantees (e.g., via hash chaining
   or inclusion proofs).

   *Log Structure*:

   {
     "session_id": "sess-uuid-12345",
     "offset": 0,
     "entry": {
       "type": "non_deterministic",
       "sub": "spiffe://example.com/agent/A",
       "input_hash": "sha256:prompt...",
       "output_hash": "sha256:abc...",
       "iat": 1700000010,
       "intent_digest": "sha256:...",
       "intent_sig": "eyJ..."
     }
   }

5.1.1.  Relationship Between session_id and jti

   The session_id is a stable identifier for the end-user interaction.
   It remains constant as the delegation chain grows through multiple
   token exchanges, each of which produces a new token with a distinct
   jti:











Krishnan, et al.        Expires 19 September 2026              [Page 14]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   User session: sess-uuid-12345

     Token Exchange 1 (jti: "tok-aaa")
       User → Agent A
       Intent entries: offset 0 (Agent A output)

     Token Exchange 2 (jti: "tok-bbb")
       Agent A → Agent B
       Intent entries: offset 1 (filter), offset 2 (Agent B output)

     Token Exchange 3 (jti: "tok-ccc")
       Agent B → Agent C
       Intent entries: offset 3 (filter), offset 4 (Agent C output)

   All intent chain entries share session_id: "sess-uuid-12345"
   regardless of which token exchange produced them.  The session_id is
   carried forward during each token exchange as part of the session
   claim.  During forensic verification, the investigator retrieves all
   entries for a session_id to reconstruct the complete content journey.

5.2.  Merkle Tree Construction

   The Merkle tree is constructed from ordered log entries.  Leaf nodes
   are the SHA-256 hashes of canonically serialized intent chain
   entries.  Internal nodes are the SHA-256 hash of the concatenation of
   their two child hashes.  When a level has an odd number of nodes, the
   last node is promoted to the next level.

   See Appendix A for a visual depiction and reference construction
   algorithm.

5.3.  Merkle Root in Token

   Only the Merkle root is included in the OAuth token:

   {
     "intent_root": "sha256:abc123def456...",
     "intent_alg": "sha256",
     "intent_registry": "https://intent-log.example.com"
   }











Krishnan, et al.        Expires 19 September 2026              [Page 15]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     +=================+========+==========+========================+
     | Field           | Type   | Required | Description            |
     +=================+========+==========+========================+
     | intent_root     | string | REQUIRED | Merkle root hash of    |
     |                 |        |          | intent chain           |
     +-----------------+--------+----------+------------------------+
     | intent_alg      | string | OPTIONAL | Hash algorithm         |
     |                 |        |          | (default: sha256)      |
     +-----------------+--------+----------+------------------------+
     | intent_registry | string | REQUIRED | URI of intent registry |
     |                 |        |          | for proof retrieval    |
     +-----------------+--------+----------+------------------------+

                                 Table 8

6.  Token Structure

6.1.  Combined Token Format

   The complete token combines session, actor chain, and intent chain:































Krishnan, et al.        Expires 19 September 2026              [Page 16]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   {
     "iss": "https://auth.example.com",
     "sub": "user-alice",
     "aud": "https://api.example.com",
     "jti": "tok-aaa-12345",
     "sid": "sess-uuid-12345",
     "iat": 1700000000,
     "exp": 1700003600,

     "session": {
       "session_id": "sess-uuid-12345",
       "type": "human_initiated",
       "initiator": "user-alice",
       "approval_ref": "approval-uuid-789",
       "max_chain_depth": 5
     },

     "actor_chain": [
       {
         "sub": "spiffe://example.com/agent/orchestrator",
         "iss": "https://auth.example.com",
         "iat": 1700000010
       },
       {
         "sub": "spiffe://example.com/agent/support",
         "iss": "https://auth.example.com",
         "iat": 1700000030
       }
     ],

     "intent_root": "sha256:abc123def456789...",
     "intent_registry":
       "https://intent-log.example.com/sessions/sess-uuid-12345"
   }

6.2.  Claim Definitions

6.2.1.  Session Claims

   +=======================+======+===================================+
   |Claim                  |Type  |Description                        |
   +=======================+======+===================================+
   |sid                    |string|Session identifier — stable across |
   |                       |      |token exchanges.  Equals           |
   |                       |      |session.session_id.  Defined as a  |
   |                       |      |top-level claim in {{!I-D.draft-mw-|
   |                       |      |spice-actor-chain}}                |
   +-----------------------+------+-----------------------------------+



Krishnan, et al.        Expires 19 September 2026              [Page 17]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   |session.session_id     |string|Stable identifier for the end-user |
   |                       |      |interaction, assigned by the AS on |
   |                       |      |first token issuance and carried   |
   |                       |      |forward during subsequent token    |
   |                       |      |exchanges.  MUST equal the top-    |
   |                       |      |level sid claim                    |
   +-----------------------+------+-----------------------------------+
   |session.type           |string|Session type: human_initiated,     |
   |                       |      |system_initiated, scheduled        |
   +-----------------------+------+-----------------------------------+
   |session.initiator      |string|Identity of session initiator      |
   +-----------------------+------+-----------------------------------+
   |session.approval_ref   |string|Reference to approval record       |
   +-----------------------+------+-----------------------------------+
   |session.max_chain_depth|number|Maximum allowed delegation depth   |
   +-----------------------+------+-----------------------------------+

                                 Table 9

6.2.2.  Actor Chain Claims

   Defined in {{!I-D.draft-mw-spice-actor-chain}}.

6.2.3.  Intent Chain Claims

   +=================+========+=======================================+
   | Claim           | Type   | Description                           |
   +=================+========+=======================================+
   | intent_root     | string | Merkle root hash of intent chain      |
   +-----------------+--------+---------------------------------------+
   | intent_alg      | string | Hash algorithm used (default: sha256) |
   +-----------------+--------+---------------------------------------+
   | intent_registry | string | URI for retrieving full chain or      |
   |                 |        | proofs (REQUIRED)                     |
   +-----------------+--------+---------------------------------------+

                                 Table 10

6.3.  Examples

6.3.1.  Minimal Token (Actor Chain Only)










Krishnan, et al.        Expires 19 September 2026              [Page 18]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   {
     "iss": "https://auth.example.com",
     "sub": "user-alice",
     "jti": "tok-bbb-12345",
     "iat": 1700000000,
     "exp": 1700003600,

     "actor_chain": [
       {
         "sub": "spiffe://example.com/agent/A",
         "iss": "https://auth.example.com",
         "iat": 1700000010
       }
     ]
   }

6.3.2.  Minimal Token (Intent Chain Only)

   {
     "iss": "https://auth.example.com",
     "sub": "user-alice",
     "jti": "tok-ccc-12345",
     "iat": 1700000000,
     "exp": 1700003600,

     "intent_root": "sha256:abc123...",
     "intent_registry":
       "https://intent-log.example.com/sessions/sess-uuid-12345"
   }

6.3.3.  Full Token (Both Chains)

   See Section 6.1.

7.  Verification Procedures

7.1.  Request-Time Policy Checks

   At request time, the Relying Party performs lightweight checks on the
   intent chain metadata in the token.  Full chain verification is
   unnecessary on the hot path because:

   *  The content has already been produced; verifying signatures cannot
      undo it.
   *  The Relying Party has the token, not the raw content, so it cannot
      cross-check content hashes.
   *  O(n) signature verification per request adds latency without
      improving authorization decisions.



Krishnan, et al.        Expires 19 September 2026              [Page 19]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   The Relying Party SHOULD:

   1.  Verify the JWT outer signature (covers intent_root as a signed
       claim).
   2.  Check that intent_root and intent_registry are present (policy:
       "intent chain coverage required").
   3.  Apply policy rules against intent chain entry types fetched from
       the registry (e.g., "must include at least one deterministic
       entry").

   The tiered verification table reflects the appropriate level of
   intent chain checking based on risk:

    +========+======================+====================+============+
    | Risk   | Actor Chain          | Intent Chain       | Use Case   |
    | Level  |                      |                    |            |
    +========+======================+====================+============+
    | Low    | Verify JWT signature | Check intent_root  | Read       |
    |        |                      | present            | operations |
    +--------+----------------------+--------------------+------------+
    | Medium | Verify JWT signature | Async policy check | Create/    |
    |        |                      | on entry types     | update     |
    +--------+----------------------+--------------------+------------+
    | High   | Verify JWT signature | Full forensic      | Delete,    |
    |        | + actor sigs         | verification       | transfer,  |
    |        |                      |                    | admin      |
    +--------+----------------------+--------------------+------------+

                                  Table 11

7.2.  Forensic Verification

   The primary value of the intent chain is post-hoc troubleshooting and
   dispute resolution.  When an incident occurs, an auditor or
   investigator performs full chain verification to determine which
   agent caused the problem.

7.2.1.  Token Archival

   Forensic verification requires two inputs: the original JWT
   (containing intent_root) and the intent chain entries from the
   registry.  The intent registry stores chain entries but does not
   store the token itself.

   To enable forensic analysis, tokens SHOULD be archived by one or more
   of the following:





Krishnan, et al.        Expires 19 September 2026              [Page 20]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   *  *Relying Parties*: Archive tokens at the point of presentation
      (most common).
   *  *Audit services*: A dedicated audit service receives a copy of
      each token for compliance purposes.
   *  *Authorization Servers*: The AS MAY maintain a log of issued
      tokens indexed by jti.

   Archived tokens MUST be stored securely and access-controlled, as
   they contain identity and delegation information.

7.2.2.  Full Chain Verification

   To perform a complete forensic investigation:

   1.  *Retrieve inputs*: Extract intent_root and intent_registry from
       the archived token.  Fetch the full intent chain from the
       registry using the session_id.
   2.  *Verify Merkle integrity*: Rebuild the Merkle tree from all
       entries.  Compare the computed root with intent_root from the
       token.  If they do not match, the chain has been tampered with.
   3.  *Verify signatures*: For each entry, verify intent_sig over
       intent_digest using the sub's public key (discoverable via SPIFFE
       trust bundle or JWKS).  A failed signature indicates a forged
       entry.
   4.  *Verify chain linkage*: For each consecutive pair, verify
       entry[i].output_hash == entry[i+1].input_hash.  A broken link
       indicates content was modified between steps without being
       recorded.
   5.  *Re-derive deterministic outputs*: For deterministic entries,
       retrieve the rule definition matching rule_hash, re-apply it to
       the content matching input_hash, and verify the output matches
       output_hash.  A mismatch indicates the filter did not behave as
       recorded.
   6.  *Identify the fault point*: If step 4 reveals a broken link at
       position k, the content was corrupted between entry[k] and
       entry[k+1].  If step 3 reveals a failed signature at position k,
       entry[k] was forged.  The sub field of the faulty entry
       identifies the responsible agent.

7.2.3.  Cross-Chain Correlation

   When used together with the actor chain, forensic verification can
   answer both *WHO* and *WHAT*:

   1.  For each intent chain entry of type non_deterministic: verify
       that entry.sub appears in the actor_chain of the same token.





Krishnan, et al.        Expires 19 September 2026              [Page 21]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   2.  Verify that entry.iat falls within the actor's active window
       (between the actor's own iat and the next actor's iat in the
       chain).
   3.  A mismatch indicates an unregistered agent produced content — the
       intent chain records output from an identity not present in the
       delegation chain.

7.2.4.  Dispute Resolution Workflow

   When a dispute arises (e.g., "Agent A did not produce that harmful
   output"):

   1.  Retrieve the archived token and full intent chain.
   2.  Locate entries where sub matches Agent A's SPIFFE ID.
   3.  Verify Agent A's intent_sig on each of those entries.  A valid
       signature proves Agent A attested to producing that specific
       output_hash.
   4.  Check input_hash of Agent A's entry to verify what Agent A
       received as input.
   5.  If Agent A's output was modified by a downstream filter, the
       filter's entry shows input_hash matching Agent A's output_hash
       and a different output_hash — proving the filter made the change,
       not Agent A.

7.2.5.  Single Entry Verification (Merkle Proof)

   To verify a single entry without fetching the full chain:

   1.  Extract intent_root from the token.
   2.  Request a Merkle proof for entry[i] from the registry.
   3.  The registry returns the entry and sibling hashes on the path to
       the root.
   4.  Compute the hash of the entry and the path to the root using
       sibling hashes.
   5.  Compare the computed root with intent_root.

   *Proof Size*: O(log n) where n is the number of entries.














Krishnan, et al.        Expires 19 September 2026              [Page 22]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   {
     "entry": {
       "type": "non_deterministic",
       "sub": "spiffe://example.com/agent/A",
       "input_hash": "sha256:prompt...",
       "output_hash": "sha256:abc...",
       "iat": 1700000010
     },
     "proof": {
       "index": 0,
       "siblings": [
         {"position": "right", "hash": "sha256:111..."},
         {"position": "right", "hash": "sha256:222..."},
         {"position": "left", "hash": "sha256:333..."}
       ]
     }
   }

8.  Operational Flows

8.1.  Intent Chain Construction






























Krishnan, et al.        Expires 19 September 2026              [Page 23]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     Agent A        Filter        Agent B       Intent
                                                Registry
        |               |               |           |
        | Produce       |               |           |
        | output        |               |           |
        |---------------+---------------+---------->|
        |               |               |  Append   |
        |               |               | non-det   |
        |               |               |   entry   |
        |               |               |           |
        | Send to       |               |           |
        | filter        |               |           |
        |-------------->|               |           |
        |               |               |           |
        |               | Transform     |           |
        |               | content       |           |
        |               |---------------+---------->|
        |               |               |  Append   |
        |               |               | filter    |
        |               |               |   entry   |
        |               |               |           |
        |               | Send to       |           |
        |               | Agent B       |           |
        |               |-------------->|           |
        |               |               |           |
        |               |               | Produce   |
        |               |               | output    |
        |               |               |---------->|
        |               |               |  Append   |
        |               |               | non-det   |
        |               |               |   entry   |
        |               |               |           |

8.2.  Token Exchange Integration

















Krishnan, et al.        Expires 19 September 2026              [Page 24]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     Agent B          AS          Intent      Actor
                                  Registry    Registry
        |               |            |            |
        | Token         |            |            |
        | Exchange      |            |            |
        | Request       |            |            |
        |-------------->|            |            |
        |               |            |            |
        |               | Validate   |            |
        |               | existing   |            |
        |               | actor_chain|            |
        |               |            |            |
        |               | Extend     |            |
        |               | actor_chain|            |
        |               |------------+----------->|
        |               |            |   Store    |
        |               |            | capability |
        |               |            |            |
        |               | Compute    |            |
        |               | intent_root|            |
        |               |----------->|            |
        |               | Get Merkle |            |
        |               | root       |            |
        |               |<-----------|            |
        |               |            |            |
        | New token     |            |            |
        | with both     |            |            |
        | chains        |            |            |
        |<--------------|            |            |
        |               |            |            |

8.3.  Request-Time Check at Relying Party



















Krishnan, et al.        Expires 19 September 2026              [Page 25]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     Agent C       Relying       Intent      Actor
                    Party        Registry    Registry
        |               |            |            |
        | Request +     |            |            |
        | Token         |            |            |
        |-------------->|            |            |
        |               |            |            |
        |               | Verify JWT |            |
        |               | signature  |            |
        |               |            |            |
        |               | Verify     |            |
        |               | actor_chain|            |
        |               | (per mode) |            |
        |               |            |            |
        |               | Check      |            |
        |               | intent_root|            |
        |               | present    |            |
        |               |            |            |
        |               | Apply      |            |
        |               | policy on  |            |
        |               | entry types|            |
        |               |----------->|            |
        |               | Fetch entry|            |
        |               | types only |            |
        |               |<-----------|            |
        |               |            |            |
        |               | Policy OK: |            |
        |               | Execute    |            |
        |               |            |            |
        | Response      |            |            |
        |<--------------|            |            |
        |               |            |            |

9.  Policy Enforcement

9.1.  Policy Examples

9.1.1.  Require All Outputs Filtered

   Every agent output must be followed by at least one filter:











Krishnan, et al.        Expires 19 September 2026              [Page 26]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   require_filtered_outputs {
       intent_chain := get_intent_chain(input.intent_root)

       agent_outputs := [i |
           intent_chain[i].type == "non_deterministic"]

       every i in agent_outputs {
           # Next entry must be a filter (if not last)
           i < count(intent_chain) - 1
           intent_chain[i + 1].type != "non_deterministic"
       }
   }

9.1.2.  Require Non-Deterministic Filter for AI Outputs

   AI agent outputs must pass through an AI guardrail:

   require_ai_guardrail {
       intent_chain := get_intent_chain(input.intent_root)

       every i, entry in intent_chain {
           entry.type == "non_deterministic" implies {
               # Must be followed by an entry with AI guardrail model
               some j
               j > i
               intent_chain[j].model_info.model ==
                   "llama-guard-3"
           }
       }
   }

9.1.3.  Verify Specific Transformation Applied

   Sensitive fields must be sanitized:

   require_pii_redaction {
       intent_chain := get_intent_chain(input.intent_root)

       some i
       intent_chain[i].type == "deterministic"
       intent_chain[i].rule_id == "pii-redaction-v1"
   }

9.2.  Integration with Policy Engines

   The intent chain claims are designed for consumption by policy
   engines such as Open Policy Agent (OPA).  A policy engine SHOULD:




Krishnan, et al.        Expires 19 September 2026              [Page 27]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   1.  Validate session expiry and revocation status.
   2.  Verify actor chain integrity (per {{!I-D.draft-mw-spice-actor-
       chain}}).
   3.  Verify intent_root and intent_registry are present and non-empty.
   4.  Evaluate deployment-specific requirements against the intent
       chain entries (e.g., requiring filtered outputs, specific
       guardrail models, or PII redaction).

10.  Security Considerations

10.1.  STRIDE Analysis

   +===============+========================+=========================+
   | Threat        | Mitigation             | Mechanism               |
   +===============+========================+=========================+
   | *Spoofing*    | Cryptographic identity | Actor chain, SPIFFE IDs |
   +---------------+------------------------+-------------------------+
   | *Tampering*   | Merkle tree integrity  | Append-only logs,       |
   |               |                        | Merkle root in JWT      |
   +---------------+------------------------+-------------------------+
   | *Repudiation* | Signed outputs         | intent_sig on agent and |
   |               |                        | filter entries          |
   +---------------+------------------------+-------------------------+
   | *Information  | Selective disclosure   | SD-JWT, content hashes  |
   | Disclosure*   |                        | not content             |
   +---------------+------------------------+-------------------------+
   | *Denial of    | Session lifecycle      | Expiry, rate limits     |
   | Service*      |                        |                         |
   +---------------+------------------------+-------------------------+
   | *Elevation of | Scope attenuation      | Actor chain, policy     |
   | Privilege*    |                        | enforcement             |
   +---------------+------------------------+-------------------------+

                                 Table 12

10.2.  Signing Requirements by Entry Type

    +===================+===============+=============================+
    | Entry Type        | Required      | Rationale                   |
    |                   | Signatures    |                             |
    +===================+===============+=============================+
    | non_deterministic | intent_sig    | Non-reproducible; signs     |
    |                   | over          | input_hash + output_hash to |
    |                   | intent_digest | prove what was received and |
    |                   | (REQUIRED)    | produced                    |
    +-------------------+---------------+-----------------------------+
    | deterministic     | intent_sig    | Reproducible; signs         |
    |                   | over          | input_hash + output_hash.   |



Krishnan, et al.        Expires 19 September 2026              [Page 28]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


    |                   | intent_digest | Type-specific fields        |
    |                   | (REQUIRED)    | (rule_id, rule_hash) enable |
    |                   |               | independent re-verification |
    +-------------------+---------------+-----------------------------+

                                  Table 13

10.3.  Replay Protection

   Each intent chain entry includes an iat (issued-at) timestamp.  The
   session-scoped partitioning of the intent registry prevents cross-
   session replay.  Additionally, the Merkle root is bound to the JWT
   via the intent_root claim, and the JWT itself carries exp and jti
   claims, providing token-level replay protection.

10.4.  Chain Integrity

   The Merkle tree structure provides tamper evidence for the intent
   chain.  Any modification to an entry changes its leaf hash, which
   propagates up the tree, changing the Merkle root.  Since the Merkle
   root is included in the signed JWT, any tampering with the intent
   chain entries is detectable.

   The append-only property of the intent registry provides additional
   protection: entries cannot be deleted or modified after creation.

10.5.  Credential Isolation

   Intent registry entries MUST NOT contain OAuth tokens, bearer
   credentials, or signing keys.  The relationship between tokens and
   registry entries is one-directional: the token references the
   registry via the intent_registry URI claim, but the registry MUST NOT
   store or reference the token.  This separation ensures that
   compromise of the intent registry does not expose bearer credentials
   that could be used for unauthorized access.

11.  Privacy Considerations

11.1.  Selective Disclosure

   The intent chain contains content hashes rather than actual content.
   This provides provenance without exposing the content itself.  When
   combined with SD-JWT {{!I-D.ietf-oauth-selective-disclosure-jwt}},
   individual intent chain entries can be selectively disclosed to
   different verifiers.






Krishnan, et al.        Expires 19 September 2026              [Page 29]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


11.2.  Content Hash vs Content Storage

   The intent chain stores SHA-256 hashes of content, not the content
   itself.  This design choice provides:

   *  *Provenance without exposure*: Verifiers can confirm that specific
      content was produced without seeing the content.
   *  *Reduced log size*: Hashes are fixed-size regardless of content
      size.
   *  *Privacy by default*: Content is not exposed through the intent
      chain; access to the original content requires separate
      authorization.

   |  *Pre-image resistance caveat*: SHA-256 is pre-image resistant for
   |  arbitrary-length inputs, but short, low-entropy content (e.g., a
   |  16-digit account number, a boolean flag, or a short enumerated
   |  value) may be vulnerable to brute-force guessing.  An attacker who
   |  knows the hash and the input domain can enumerate all possible
   |  inputs and find the one that matches.  Deployments handling short,
   |  structured content SHOULD salt content before hashing or use SD-
   |  JWT to selectively redact content hashes from specific verifiers.

12.  Implementation Guidance

12.1.  Intent Registry Implementation

   The intent registry stores immutable intent chain entries.
   Recommended properties:

   *  Append-only log structure
   *  Partitioned by session.session_id for isolation
   *  Configurable retention period
   *  Merkle root computation triggered on append or at token exchange
      time

   A federated IAM/IdM platform (e.g., Keycloak, Microsoft Entra, Okta,
   PingFederate) MAY host the intent registry alongside the Actor Chain
   Registry ({{!I-D.draft-mw-spice-actor-chain}}), since the
   Authorization Server already mediates token exchanges and can append
   intent chain entries as a side-effect.  Most enterprise IAM/IdM
   platforms support configurable data stores that can be configured for
   append-only semantics — see {{!I-D.draft-mw-spice-actor-chain}}
   Section "Registry Hosting" for detailed requirements.








Krishnan, et al.        Expires 19 September 2026              [Page 30]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


12.2.  Multi-AS Deployments

   In deployments involving multiple Authorization Servers (e.g.,
   federated enterprise environments where different ASes serve
   different organizational domains), the intent registry is shared
   across all participating ASes.  Each AS appends intent chain entries
   to the same session-partitioned registry, identified by the sid claim
   carried in the token.  This works without coordination between ASes
   because:

   *  The sid value is established at session initiation and carried
      forward unchanged through all token exchanges.
   *  Each AS appends entries atomically under the session's sid
      partition.
   *  The Merkle root is recomputed at each token exchange time over all
      entries accumulated so far (by any AS).
   *  The resulting intent_root in the token therefore differs at each
      hop — each successive AS produces a larger Merkle root reflecting
      the growing chain.  This is expected behavior: a growing root is
      the normal consequence of an append-only chain and indicates that
      additional intent entries have been recorded.

   This enables cross-domain content provenance tracking without
   requiring ASes to share keys or coordinate directly — the session
   partition and append-only log semantics provide the necessary
   consistency.

12.3.  Scalability Considerations

   *  *Log Partitioning*: Session-based partitioning ensures that intent
      chains for different sessions are isolated and can be processed in
      parallel.
   *  *Merkle Root Caching*: Computed Merkle roots SHOULD be cached to
      avoid recomputation on every token exchange.
   *  *Proof Materialization*: Merkle proofs for recent entries SHOULD
      be pre-computed and cached for O(1) retrieval.

12.4.  Operational Recommendations

   *  *Retention Policy*: Intent chain logs SHOULD be retained for the
      maximum audit window required by the deployment's regulatory
      environment.
   *  *Monitoring*: Operators SHOULD monitor intent chain append latency
      and Merkle root computation time.
   *  *Backup*: Intent chain logs SHOULD be replicated across
      availability zones for durability.





Krishnan, et al.        Expires 19 September 2026              [Page 31]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


12.5.  Registry Availability

   Intent registry unavailability does not affect data-plane operation —
   the token's AS-signed intent_root is sufficient for request-time
   policy decisions (e.g., "intent chain coverage required").  Per-entry
   forensic verification is deferred to the audit plane and is not
   required on the hot path.

   However, if the registry is permanently lost, forensic verification
   becomes impossible.  Deployments SHOULD:

   *  Replicate intent registry entries across availability zones.
   *  Use append-only log services designed for high durability (e.g.,
      SCITT transparency logs).
   *  Retain archived tokens (containing intent_root) separately from
      intent chain entries, so that Merkle root commitments survive
      independently of the registry.
   *  Define a fail-mode policy: *fail-closed* (reject tokens whose
      intent chains cannot be verified) for high-risk operations, or
      *fail-open* (accept the AS-signed token and log the verification
      gap) for low-risk operations.

13.  Design Rationale: Merkle Root in Token

   The intent chain uses a Merkle root in the token rather than
   embedding the full chain inline.  The following table summarizes the
   trade-offs:
























Krishnan, et al.        Expires 19 September 2026              [Page 32]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   +============+=========+==============+============+================+
   | Approach   |Token    | Verification | Privacy    | Selective      |
   |            |Size     |              |            | Verify         |
   +============+=========+==============+============+================+
   | *A.  Full  |O(n) —   | Inline, zero | Poor — all | All-or-nothing |
   | chain in   |grows    | latency      | entries    |                |
   | token*     |per      |              | exposed    |                |
   |            |entry    |              |            |                |
   +------------+---------+--------------+------------+----------------+
   | *B.        |O(1) —   | O(log n) per | Good —     | Single-entry   |
   | Merkle     |~64      | entry        | selective  | proofs         |
   | root in    |bytes    |              | disclosure |                |
   | token*     |         |              |            |                |
   +------------+---------+--------------+------------+----------------+
   | *C.        |O(1) —   | O(n) — must  | Good —     | Must verify    |
   | Simple     |~64      | rehash all   | external   | all            |
   | hash of    |bytes    |              | storage    |                |
   | chain*     |         |              |            |                |
   +------------+---------+--------------+------------+----------------+
   | *D.  No    |Zero     | External     | Best —     | Any pattern    |
   | provenance |overhead | lookup       | nothing in |                |
   | in token*  |         |              | token      |                |
   +------------+---------+--------------+------------+----------------+

                                  Table 14

   Approach B is chosen because intent chains can contain 20-50+
   entries, making inline embedding impractical for data-plane proxies.
   The Merkle tree enables O(log n) selective verification of individual
   entries and provides cryptographic binding between the token and the
   registry.  The actor chain ({{!I-D.draft-mw-spice-actor-chain}}) uses
   approach A because delegation chains are small (typically 3-5
   entries) and every Relying Party needs the full delegation path.

14.  Audit Procedures

14.1.  Cross-Chain Binding

   When auditing actor and intent chains together, the auditor performs
   cross-chain binding checks:

   For each intent chain entry of type non_deterministic: verify that
   entry.sub appears in actor_chain.  Verify that entry.iat falls within
   the actor's active window.  A mismatch indicates an unregistered
   agent produced content.

   Full two-chain audit is RECOMMENDED for regulatory submissions,
   dispute resolution, and post-breach forensic analysis.



Krishnan, et al.        Expires 19 September 2026              [Page 33]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


15.  IANA Considerations

15.1.  JWT Claim Registration

   This document requests registration of the following claims in the
   "JSON Web Token Claims" registry established by {{!RFC7519}}:

   *  *Claim Name*: intent_root

   *  *Claim Description*: Merkle root hash of the intent chain for
      content provenance verification.

   *  *Change Controller*: IETF

   *  *Specification Document(s)*: [this document]

   *  *Claim Name*: intent_alg

   *  *Claim Description*: Hash algorithm used for intent chain Merkle
      tree construction.

   *  *Change Controller*: IETF

   *  *Specification Document(s)*: [this document]

   *  *Claim Name*: intent_registry

   *  *Claim Description*: URI of the intent registry for proof
      retrieval.

   *  *Change Controller*: IETF

   *  *Specification Document(s)*: [this document]

15.2.  CWT Claim Registration

   This document requests registration of the following claims in the
   "CBOR Web Token (CWT) Claims" registry established by {{!RFC8392}}:

   *  *Claim Name*: intent_root

   *  *Claim Description*: Merkle root hash of the intent chain.

   *  *CBOR Key*: TBD (e.g., 50)

   *  *Claim Type*: tstr

   *  *Change Controller*: IETF



Krishnan, et al.        Expires 19 September 2026              [Page 34]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   *  *Specification Document(s)*: [this document]

   *  *Claim Name*: intent_registry

   *  *Claim Description*: URI of the intent registry for proof
      retrieval.

   *  *CBOR Key*: TBD (e.g., 51)

   *  *Claim Type*: tstr

   *  *Change Controller*: IETF

   *  *Specification Document(s)*: [this document]

   *  *Claim Name*: intent_alg

   *  *Claim Description*: Hash algorithm used for intent chain Merkle
      tree construction.

   *  *CBOR Key*: TBD (e.g., 52)

   *  *Claim Type*: tstr

   *  *Change Controller*: IETF

   *  *Specification Document(s)*: [this document]

Appendix A.  Merkle Tree Construction Details

A.1.  Tree Structure

                       intent_root (in JWT)
                             |
                   +---------+---------+
                   |                   |
             Hash(0-2)              Hash(3-5)
                   |                   |
           +-------+-------+   +-------+-------+
           |               |   |               |
        Hash(0-1)      Hash(2) Hash(3-4)    Hash(5)
           |               |       |           |
       +---+---+           |   +---+---+       |
       |       |           |   |       |       |
    Entry0  Entry1     Entry2 Entry3 Entry4  Entry5
    (non-det)(non-det) (det)  (non-det)(det) (non-det)





Krishnan, et al.        Expires 19 September 2026              [Page 35]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


A.2.  Reference Construction Algorithm

   def compute_merkle_root(entries):
       if len(entries) == 0:
           return None

       # Compute leaf hashes
       hashes = [sha256(canonical_json(entry)) for entry in entries]

       # Build tree bottom-up
       while len(hashes) > 1:
           next_level = []
           for i in range(0, len(hashes), 2):
               if i + 1 < len(hashes):
                   combined = sha256(hashes[i] + hashes[i+1])
               else:
                   combined = hashes[i]  # Odd node promoted
               next_level.append(combined)
           hashes = next_level

       return hashes[0]

Appendix B.  Complete Token Examples

B.1.  Full Governance Token

   The following example shows a complete token with session, actor
   chain, and intent chain:























Krishnan, et al.        Expires 19 September 2026              [Page 36]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   {
     "iss": "https://auth.example.com",
     "sub": "user-alice",
     "aud": "https://api.example.com",
     "jti": "tok-ddd-67890",
     "iat": 1700000000,
     "exp": 1700003600,

     "session": {
       "session_id": "sess-uuid-12345",
       "type": "human_initiated",
       "initiator": "user-alice",
       "approval_ref": "approval-uuid-789",
       "max_chain_depth": 5
     },

     "actor_chain": [
       {
         "sub": "spiffe://example.com/agent/orchestrator",
         "iss": "https://auth.example.com",
         "iat": 1700000010,
         "scope": "ticket:*",
         "chain_digest": "sha256:aaa...",
         "chain_sig": "eyJhbGciOiJFUzI1NiIs..."
       },
       {
         "sub": "spiffe://example.com/agent/support",
         "iss": "https://auth.example.com",
         "iat": 1700000030,
         "scope": "ticket:create",
         "chain_digest": "sha256:bbb...",
         "chain_sig": "eyJhbGciOiJFUzI1NiIs..."
       }
     ],

     "intent_root": "sha256:abc123def456789...",
     "intent_registry":
       "https://intent-log.example.com/sessions/sess-uuid-12345"
   }

B.2.  Corresponding Intent Chain Log Entries

   The following entries would be stored in the intent registry for the
   above token:







Krishnan, et al.        Expires 19 September 2026              [Page 37]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   [
     {
       "offset": 0,
       "entry": {
         "type": "non_deterministic",
         "sub":
           "spiffe://example.com/agent/orchestrator",
         "input_hash": "sha256:prompt...",
         "output_hash": "sha256:abc...",
         "iat": 1700000010,
         "intent_digest": "sha256:leaf0...",
         "intent_sig": "eyJ..."
       }
     },
     {
       "offset": 1,
       "entry": {
         "type": "non_deterministic",
         "sub":
           "spiffe://example.com/filter/ai-guardrail",
         "filter_version": "v2.1",
         "input_hash": "sha256:abc...",
         "output_hash": "sha256:def...",
         "model_info": {
           "model": "llama-guard-3",
           "categories": ["violence", "pii"]
         },
         "iat": 1700000012,
         "intent_digest": "sha256:leaf1...",
         "intent_sig": "eyJ..."
       }
     },
     {
       "offset": 2,
       "entry": {
         "type": "deterministic",
         "sub":
           "spiffe://example.com/filter/schema-validator",
         "filter_version": "v1.0",
         "input_hash": "sha256:def...",
         "output_hash": "sha256:ghi...",
         "rule_id": "ticket-schema-v2",
         "rule_hash": "sha256:rrr...",
         "reproducible": true,
         "iat": 1700000013,
         "intent_digest": "sha256:leaf2...",
         "intent_sig": "eyJ..."
       }



Krishnan, et al.        Expires 19 September 2026              [Page 38]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     },
     {
       "offset": 3,
       "entry": {
         "type": "non_deterministic",
         "sub":
           "spiffe://example.com/agent/support",
         "input_hash": "sha256:ghi...",
         "output_hash": "sha256:jkl...",
         "iat": 1700000030,
         "intent_digest": "sha256:leaf3...",
         "intent_sig": "eyJ..."
       }
     },
     {
       "offset": 4,
       "entry": {
         "type": "deterministic",
         "sub":
           "spiffe://example.com/filter/pii-redactor",
         "filter_version": "v1.2",
         "input_hash": "sha256:jkl...",
         "output_hash": "sha256:mno...",
         "rule_id": "pii-redaction-v1",
         "rule_hash": "sha256:ppp...",
         "reproducible": true,
         "iat": 1700000031,
         "intent_digest": "sha256:leaf4...",
         "intent_sig": "eyJ..."
       }
     },
     {
       "offset": 5,
       "entry": {
         "type": "non_deterministic",
         "sub":
           "spiffe://example.com/agent/tool-executor",
         "input_hash": "sha256:mno...",
         "output_hash": "sha256:pqr...",
         "iat": 1700000050,
         "intent_digest": "sha256:leaf5...",
         "intent_sig": "eyJ..."
       }
     }
   ]

Authors' Addresses




Krishnan, et al.        Expires 19 September 2026              [Page 39]

Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


   Ram Krishnan
   JPMorgan Chase & Co
   Email: ramkri123@gmail.com


   A Prasad
   Oracle
   Email: a.prasad@oracle.com


   Diego R. Lopez
   Telefonica
   Email: diego.r.lopez@telefonica.com


   Srinivasa Addepalli
   Aryaka
   Email: srinivasa.addepalli@aryaka.com

































Krishnan, et al.        Expires 19 September 2026              [Page 40]
