I-D Action: draft-sato-soos-acd-03.txt

[[e-mail]]

Internet-Draft draft-sato-soos-acd-03.txt is now available.

   Title:   The Agent Compliance Disclosure (ACD) Protocol for Agentic AI Systems
   Author:  Tom Sato
   Name:    draft-sato-soos-acd-03.txt
   Pages:   38
   Dates:   2026-09-07

Abstract:

   A regulated resource provider -- a bank, a government API, a
   healthcare records system -- receives a request from an AI agent.
   The agent claims to operate under a constitutional compliance policy
   and a valid mandate.  The resource provider has no mechanism to
   verify these claims.  Without a machine-verifiable compliance
   disclosure, the resource provider cannot confirm the agent's
   governing law, its active prohibition set, its audit trail
   reference, or its principal hierarchy -- before granting access.

   This document defines the Agent Compliance Disclosure (ACD)
   Protocol: a machine-to-machine compliance handshake that must
   complete before an AI agent is granted access to a regulated
   resource class.  ACD defines the ACD Record schema (a three-layer
   structured disclosure produced by the SOOS kernel, covering legal
   identity, constitutional compliance, and principal hierarchy), the
   ACD Presentation Protocol (the query/response exchange between a
   resource provider and the SOOS kernel), the ACD Trust Hierarchy
   (operator-declared trust levels and Audit Principal credentials),
   the ACD-to-MJWT binding (ACD MUST reference the session MJWT jti),
   and the GAR integration (ACD presentation events as Authority
   Lifecycle Events).  ACD Records are produced exclusively by the
   Governing Enforcement Component (GEC), signed by the kernel's KIA
   private key, and logged in the Governance Audit Record (GAR).  LLM
   self-report of compliance posture is architecturally insufficient
   and MUST NOT be used as an ACD disclosure surface.

   ACD is the inbound complement to the Resource Governance Protocol
   (RGP): where RGP governs outbound capability discovery, ACD governs
   inbound compliance verification.  Together they define the complete
   resource access governance flow for SOOS-governed agents.

   Version -02 added the aep_session_id Layer 3 field, distinct from
   acd_session_id, to bind a cached ACD Record to the specific AEP
   session it was produced within (Section 6.3); strengthened the
   ACD Record Replay defense that checks this binding from a SHOULD
   to a MUST (Section 12.4); added the confirmation_basis field
   (NOTIFIED | INFERRED) to ALE-058 so an auditor can distinguish a
   confirmed validation pass from one merely inferred from the
   absence of a failure record (Section 10.1); added Compliance
   Handshake Volumetric Abuse as a new security consideration
   (Section 12.5); and migrated the KEE-1 citation from the versioned
   [I-D.sato-soos-kee] form to the non-versioned [SOOS-KEE] form,
   since KEE-1 is a permanent local-only specification that will
   never be submitted to the IETF Datatracker.

   Version -03 is an editorial revision with no normative content
   changes: six sibling-draft citations in Section 15.1 had gone
   stale against those drafts' current live versions and are updated
   to draft-sato-soos-aep-04, draft-sato-soos-gar-08,
   draft-sato-soos-kia-07, draft-sato-soos-mjwt-06,
   draft-sato-soos-rgp-02, and draft-sato-soos-sov-04 respectively;
   and the Table of Contents, which omitted Section 12.5 from -02's
   submission, now lists it correctly.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-sato-soos-acd/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-sato-soos-acd-03

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-sato-soos-acd-03

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts