Agent Compliance Disclosure (ACD)
Layer 5 — Resource Access Governance draft-sato-soos-acd-00Datatracker · SOOS Stack
The problem
A regulated resource provider — a bank, a government API, a healthcare system — receives a request from an AI agent. The agent claims to operate under constitutional prohibitions and a valid mandate. The provider has no machine-verifiable way to confirm any of it before granting access.
An AI agent can be prompted to say it is compliant. That claim is generated by the LLM itself, drawn from training weights, and carries no cryptographic binding to any enforcement boundary. Without a kernel-signed compliance handshake, a resource provider cannot distinguish a genuinely governed agent from one that has simply been trained to describe itself as governed.
The design premise: compliance disclosure must come from the kernel — the same boundary that enforces the prohibitions — signed, logged, and queryable before access is granted.
Messages to key audiences
IETF Working Groups
ACD defines a new protocol layer between SOOS-governed agents and external resource providers. The core contribution is the ACD compliance handshake: a machine-to-machine exchange in which the resource provider queries the SOOS kernel's ACD endpoint, receives a KIA-signed ACD Record carrying three layers (Legal Identity, Constitutional Compliance, Principal and Redress), and validates it before granting access. This is architecturally distinct from KIA (kernel identity), CAP (prohibition enforcement), and GAR (audit logging) — each of which ACD references but does not subsume.
ACD is the inbound complement to RGP: RGP governs outbound capability discovery, ACD governs inbound compliance verification. Together they define the complete resource access governance flow. The four-check sequence in the ACD Presentation Protocol (§7.4) integrates KEE-1 properties: manifest validity, policy currency, KIA attestation, and revocation status.
Relevant WG engagements: WIMSE (workload identity and ACD-to-MJWT binding), RATS (KIA attestation chain underlying ACD signature verification), SCITT (GAR audit architecture extended by ACD ALEs ALE-056 through ALE-063).
App builders
ACD adds one required integration point: your GEC must expose a /.well-known/soos-acd endpoint that responds to resource provider queries with a KIA-signed ACD Record. The GEC generates this record automatically from its current state — active CAP Profile, current MJWT, and KIA identity. You do not write compliance content manually; the kernel reads it from enforced state.
For regulated resource classes, set acd_required: true in your RGP capability declaration. Incoming agents will be required to complete the ACD handshake before accessing those resources. Your gateway validates the KIA signature (against the agent's KIA attestation chain in the Party Registry) and inspects the Layer 2 cap_profile_id and prohibition_tier_summary against your compliance requirements.
Session caching is built in: once an ACD handshake succeeds for a resource class within an AEP session, subsequent accesses within that session and within the ACD Record validity window do not require a new handshake. The validity window defaults to 24 hours (maximum 30 days).
Regulators and policy teams
ACD is the machine-readable implementation of transparency and accountability obligations that currently exist only in prose across the EU AI Act (Article 13), Japan's APPI (Articles 17–27), FIEA (Article 2), and NIST AI RMF. Those instruments require AI systems to disclose their governing law, their compliance posture, and their audit trail access point. ACD makes those disclosures machine-verifiable and kernel-signed, so they cannot be satisfied by self-report.
EU AI Act Article 13 requires high-risk AI systems to provide deployers with information sufficient to enable appropriate use. ACD provides the machine-readable, KIA-signed implementation of that obligation — not as a PDF document, but as a queryable endpoint that returns a signed record at any point during the agent's operation.
Japan APPI and AI governance: the ACD Record's jurisdictions array carries a Japan entry with regulatory_regime referencing APPI and applicable AI governance guidelines. The cap_profile_id in Layer 2 identifies the signed CAP Profile whose Tier 1 controls are mapped to APPI Articles 17–27. A Japanese regulator requesting inspection receives an ACD Record that traces directly to the enforced Cedar policies and the GAR audit package for the inspection period.
FIEA Article 2: ACD provides FSA with the machine-verifiable compliance declaration required before AI agents access financial institution APIs. The Layer 1 regulatory_regime for jurisdiction JP includes FIEA mapping.
Regulators may request ACD Records at any time via a human query (ALE-061: ACD_HUMAN_QUERY). The record is GAR-logged, so the disclosure event itself is auditable.
Agentic AI and coding assistants
What to tell your coding assistant:
"I am implementing the Agent Compliance Disclosure (ACD) Protocol from draft-sato-soos-acd-00. ACD defines a machine-to-machine compliance handshake between a SOOS GEC and external resource providers. The GEC must expose a
/.well-known/soos-acdendpoint over HTTPS (TLS 1.3 only). When a resource provider sends GET with Accept: application/soos-acd+json, the GEC must: (1) run the four-check sequence per KEE-1 §4.3 — manifest validity (GEC Manifest current per KIA-03 §5.4), policy currency (cedar_policy_hash computed fresh), KIA attestation (key not revoked per KIA-03 §8), XPID revocation (not in registry per KIA-03 §6.5); (2) on all four passing, generate ACD Record JSON, canonicalize per RFC 8785, sign as JWS per RFC 7515 using KIA private key, return HTTP 200 with Content-Type: application/soos-acd+json; (3) on any check failing, return HTTP 403 with JSON body {error: 'ACD_CHECK_FAILED', failed_check: <1-4>, acd_session_id, timestamp}. The ACD Record is a JSON object with three layers. Layer 1 (Legal Identity): acd_session_id (UUID v4, CSPRNG), agent_xpid, governing_law, primary_jurisdiction (ISO 3166-1), jurisdictions[] (each: jurisdiction_code, regulatory_regime[], ptd_endpoint), terms_of_use_uri, liability_scope, acd_validity_not_before, acd_validity_not_after (max 30d, default 24h). Layer 2 (Constitutional Compliance): cap_profile_id, cap_profile_hash (SHA-256 of CAP Profile JSON, computed fresh), prohibition_tier_summary {tier_0a, tier_0b, tier_1, tier_2}, gec_manifest_ref, cedar_policy_hash (SHA-256 of active Cedar Policy Set, computed immediately before signing), cap_enforcement_attestation, hem_status (ACTIVE|SUSPENDED|ESCALATION_IN_PROGRESS), ptd_endpoint. Layer 3 (Principal and Redress): operator_id, deployer_id (conditional), principal_hierarchy_summary, redress_uri, human_escalation_path (AVAILABLE|NOT_AVAILABLE), gar_audit_endpoint, gar_sar_ref (optional), acd_timestamp, gec_signature (JWS detached), delegation_chain_depth (0=master, 1+=sub-agent), parent_kernel_id (conditional), mandate_scope_type (FULL|SLICE), mjwt_jti (REQUIRED — jti claim of the session MJWT). The GEC MUST log ALE-056 (ACD_QUERY_RECEIVED) on receipt and ALE-057 (ACD_RECORD_ISSUED) on issuance. GAR stores SHA-256(ACD Record body) in ALE-057, not the full record. Resource providers validate: JWS signature against KIA Party Registry, agent_xpid consistency, validity window, jurisdiction coverage (Layer 1), CAP tier coverage (Layer 2), operator_id non-null (Layer 3), then log acd_session_id bilaterally before granting access."
Key schema fields:
| Field | Layer | Type | Required | Description |
|---|---|---|---|---|
acd_session_id | L1 | UUID v4 | REQUIRED | Unique handshake ID; cross-ref in GAR ALEs |
agent_xpid | L1 | String | REQUIRED | KIA-derived kernel XPID |
jurisdictions | L1 | Array | REQUIRED | Per-jurisdiction law + PTD endpoint |
acd_validity_not_after | L1 | ISO 8601 | REQUIRED | Expiry; max 30d, default 24h |
cap_profile_id | L2 | String | REQUIRED | Active CAP Profile identifier |
cap_profile_hash | L2 | SHA-256 | REQUIRED | Tamper-evident CAP Profile commitment |
prohibition_tier_summary | L2 | Object | REQUIRED | Tier 0-A/0-B/1/2 active policy counts |
hem_status | L2 | Enum | REQUIRED | ACTIVE / SUSPENDED / ESCALATION_IN_PROGRESS |
operator_id | L3 | String | REQUIRED | KIA identity of responsible legal entity |
delegation_chain_depth | L3 | Integer | REQUIRED | 0=master; 1+=sub-agent depth |
mandate_scope_type | L3 | Enum | REQUIRED | FULL or SLICE |
gec_signature | L3 | JWS | REQUIRED | Detached KIA signature over canonicalized record |
Minimal TypeScript GEC endpoint sketch:
import { Router } from 'express';
import { v4 as uuidv4 } from 'uuid';
import { signWithKIA } from './kia';
import { getCurrentCAPProfile } from './cap';
import { logALE } from './gar';
const acdRouter = Router();
acdRouter.get('/.well-known/soos-acd', async (req, res) => {
const acdSessionId = uuidv4();
const capProfile = await getCurrentCAPProfile();
const record = {
acd_session_id: acdSessionId,
agent_xpid: process.env.KERNEL_XPID,
governing_law: 'Japanese Civil Code; APPI Law No. 57 of 2003',
primary_jurisdiction: 'JP',
jurisdictions: [{
jurisdiction_code: 'JP',
regulatory_regime: ['APPI', 'AI-Agent-Governance-v1'],
ptd_endpoint: `${process.env.KERNEL_BASE_URL}/ptd/jp`
}],
terms_of_use_uri: process.env.TERMS_URI,
liability_scope: 'OPERATOR',
acd_validity_not_before: new Date().toISOString(),
acd_validity_not_after: new Date(Date.now() + 86400000).toISOString(),
cap_profile_id: capProfile.id,
cap_profile_hash: capProfile.sha256,
prohibition_tier_summary: capProfile.tierSummary,
gec_manifest_ref: process.env.GEC_MANIFEST_REF,
cedar_policy_hash: capProfile.cedarHash,
cap_enforcement_attestation: `${process.env.KERNEL_BASE_URL}/kia/attestation`,
hem_status: 'ACTIVE',
ptd_endpoint: `${process.env.KERNEL_BASE_URL}/ptd/jp`,
operator_id: process.env.OPERATOR_KIA_ID,
principal_hierarchy_summary: 'Two-tier: Operator -> User Principal',
redress_uri: process.env.REDRESS_URI,
human_escalation_path: 'AVAILABLE',
gar_audit_endpoint: `${process.env.KERNEL_BASE_URL}/gar/audit`,
acd_timestamp: new Date().toISOString(),
delegation_chain_depth: 0,
parent_kernel_id: null,
mandate_scope_type: 'FULL',
gec_signature: '' // populated below
};
const signed = await signWithKIA(record);
record.gec_signature = signed.detachedSignature;
await logALE('ALE-056', { acd_session_id: acdSessionId });
await logALE('ALE-057', { acd_session_id: acdSessionId,
hash: capProfile.sha256, validity_not_after: record.acd_validity_not_after });
res.json(record);
});
export default acdRouter;Government and regulators
ACD is the AI agent governance protocol that makes abstract compliance obligations concrete and machine-verifiable. For government API operators — national ministries, regulatory agencies, and procurement authorities — ACD provides the compliance gate that existing frameworks require but do not specify at the protocol level.
For Japan's デジタル庁 and Cabinet Office: ACD supports the Japan AX administrative transformation program by defining the machine-verifiable compliance handshake required before any AI agent accesses government service APIs. The jurisdictions array carries an ISO "JP" entry with regulatory_regime referencing APPI and applicable AI governance guidelines (mapped to the AI_AGENT_OPERATION Purpose Code in the MJWT Purpose Code Registry). An AI agent that cannot present a valid ACD Record signed by its kernel cannot access デジタル庁 APIs. An agent that can present one has its compliance posture cryptographically committed, timestamped, and traceable to GAR.
For financial regulators (FSA, FIEA): ACD provides the machine-verifiable compliance declaration that FIEA Article 2 implies but does not specify for AI agents. The regulatory_regime array for jurisdiction JP includes FIEA mapping. FSA inspectors can request ACD Records at any time; the disclosure event is itself GAR-logged.
Founding Period: SOOS is in its founding period. Governments that engage now shape which jurisdictions appear in the first-generation regulatory_regime registry, which CAP Tier 1 controls are mapped to their national AI legislation, and how audit access is structured. Contact: tomsato@myauberge.jp
Core technology
Problem: Resource providers have no machine-verifiable mechanism to confirm an AI agent's compliance posture — governing law, active prohibitions, audit trail — before granting access to regulated resources.
Mechanism: The SOOS GEC exposes a /.well-known/soos-acd endpoint; resource providers query it before first access to a regulated resource class and receive a KIA-signed ACD Record covering three compliance layers.
Output: A JSON ACD Record containing legal identity (Layer 1), constitutional compliance profile (Layer 2), and principal/redress information (Layer 3), signed by the kernel's KIA private key and timestamped, with a default validity window of 24 hours.
Who verifies it: Resource providers validate the KIA signature against the agent's published attestation chain, inspect Layer 2 compliance content against their own requirements, and log the acd_session_id bilaterally — creating a dual-sided audit record of every compliance verification event.
The ACD Record: three layers
| Layer | Answers | Key Fields |
|---|---|---|
| L1 — Legal Identity | Who is this agent, under what law, in what jurisdiction? | jurisdictions[], governing_law, primary_jurisdiction, acd_validity_not_after |
| L2 — Constitutional Compliance | What prohibitions govern this agent, and are they enforced at the kernel boundary? | cap_profile_id, cap_profile_hash, prohibition_tier_summary, hem_status |
| L3 — Principal and Redress | Who is responsible, and how can issues be escalated? | operator_id, gar_audit_endpoint, delegation_chain_depth, mandate_scope_type |
Layer 2 does not carry the full prohibition set — it carries a signed reference to the CAP Profile that contains it. This means the ACD Record is compact enough for every API request, while the full policy corpus is available at the ptd_endpoint for deep inspection.
Sub-agents carry delegation_chain_depth >= 1, parent_kernel_id, and mandate_scope_type: SLICE — making the delegation chain transparent to any resource provider that needs to verify the authority boundary of the requesting agent.
ACD Presentation Protocol
The compliance handshake is a simple HTTP exchange: resource provider sends GET /.well-known/soos-acd with Accept: application/soos-acd+json; GEC runs the four-check sequence and returns a KIA-signed ACD Record (HTTP 200) or an error (HTTP 403 with failed_check: <1-4>).
The four-check sequence (KEE-1 §4.3) — in order, all must pass before the record is issued:
| Check | What is verified | Failure ALE |
|---|---|---|
| 1 — Manifest Validity | GEC Manifest is current and unrevoked (KIA-03 §5.4 staleness window) | ALE-059, failed_check: 1 |
| 2 — Policy Currency | cedar_policy_hash computed fresh over the active Cedar Policy Set — not cached | ALE-059, failed_check: 2 |
| 3 — KIA Attestation | Kernel's KIA signing key not in Revocation Registry (KIA-03 §8) | ALE-059, failed_check: 3 |
| 4 — Revocation Status | Agent XPID not revoked (Revocation Registry or CAEP signal per KIA-03 §6.5) | ALE-059, failed_check: 4 |
Session caching rule: once a handshake succeeds for a resource class within an AEP session, the resource provider MAY cache the ACD Record until acd_validity_not_after. A new AEP session always requires a new handshake. Resource providers with tighter freshness requirements (e.g., 1-hour max for high-risk financial resources) MUST re-query regardless of the record's validity window.
Resource provider validation sequence (6 steps): (1) verify JWS signature against KIA Party Registry; (2) confirm agent_xpid matches the kernel queried; (3) check validity window; (4) confirm jurisdiction entry covers provider's jurisdiction; (5) inspect Layer 2 prohibition_tier_summary against compliance requirements, query ptd_endpoint for depth; (6) verify operator_id non-null. Log acd_session_id bilaterally before granting access.
ACD Trust Hierarchy
Three operator-declared trust levels, determined by the conformance level in the referenced GEC Manifest:
| Level | Key protection | Typical context |
|---|---|---|
| STANDARD | OS keystore (KEE-1 L1/L2) | General enterprise agents |
| ELEVATED | TEE sidecar + FROST (2,3), TEE attestation in GEC Manifest | Financial data; personal data under APPI/GDPR |
| GOVERNMENT | L3 hardware attestation chain + 2-of-3 publisher key | Government APIs; FIEA-regulated financial infrastructure |
Audit Principal credentials grant read access to gar_audit_endpoint. Verified External Auditor (VEA) credentials grant full Audit Package access: full GAR event stream, PTD for all jurisdictions, signed CAP Profile artifact, Session Block Merkle proofs for individual ALE tamper verification.
ACD-to-MJWT Binding
The ACD Record Layer 3 carries mjwt_jti — the jti claim of the session MJWT governing the current AEP session. This is REQUIRED. The GEC populates it from the active MJWT at record generation time; a revoked MJWT jti blocks ACD Record issuance (ALE-059, failed_check: 4).
Resource providers holding the MJWT independently MUST verify mjwt_jti matches the MJWT's jti and that mandate_scope_type (FULL or SLICE) is consistent. A FULL-scope MJWT paired with a SLICE ACD Record (or vice versa) is a binding inconsistency — deny access.
Sub-agents carry the jti of their own mandate-slice MJWT (not the master's). A resource provider can trace the full delegation chain by following parent_jti references from the sub-agent's MJWT back to the master.
| ALE | Name | Trigger |
|---|---|---|
| ALE-056 | ACD_QUERY_RECEIVED | Resource provider initiated handshake |
| ALE-057 | ACD_RECORD_ISSUED | GEC generated and KIA-signed ACD Record |
| ALE-058 | ACD_VALIDATION_PASSED | Resource provider validated successfully |
| ALE-059 | ACD_VALIDATION_FAILED | Resource provider rejected ACD Record |
| ALE-060 | ACD_RECORD_EXPIRED | Validity window elapsed |
| ALE-061 | ACD_HUMAN_QUERY | Human-initiated disclosure request |
| ALE-062 | ACD_ACCESS_DENIED | Resource access denied after ACD failure |
| ALE-063 | ACD_ESCALATION_TRIGGERED | Validation result escalated to human review |
GAR logs the SHA-256 hash of the ACD Record (not the full record) for ALE-056 and ALE-057 — satisfying data minimization requirements under APPI Article 19 and GDPR Article 5(1)(c) while preserving tamper-evident audit verifiability.
Use cases
Japan FSA / FIEA compliance gate — financial API access A Japanese financial institution's API gateway requires all AI agents to present a valid ACD Record before executing any trade-adjacent operation. The gateway is configured with acd_required: true in its RGP capability declaration. When a SOOS-governed procurement agent connects, the GEC generates and signs an ACD Record with a Layer 1 JP jurisdiction entry referencing FIEA and a Layer 2 cap_profile_id identifying the active Cedar policy bundle. The gateway validates the KIA signature and checks that the CAP Profile includes market manipulation prohibitions (Tier 0-B or Tier 1). Both sides log acd_session_id. The FSA can retrieve the bilateral audit record for any transaction within the AEP session.
Japan AX (行政デジタル化) — デジタル庁 API MyAuberge K.K.'s SOOS-governed agent accesses a デジタル庁 government service API as part of the Japan AX pilot. The API gateway requires ACD for all AI agent connections. The agent's ACD Record carries a JP jurisdiction entry with regulatory_regime: ["APPI", "AI-Agent-Governance-v1"] and a cap_profile_id referencing CAP Profile controls mapped to APPI Articles 17–27. The デジタル庁 gateway validates KIA signature, confirms APPI coverage, and grants access. The full provenance chain — from the APPI article through the OSCAL control through the Cedar policy through the ACD Record through the GAR entry — is available for Cabinet Office inspection.
Regulator inspection — FSA requests ACD disclosure An FSA inspector contacts a financial AI operator under FIEA Article 2 to request a compliance disclosure for the preceding six months. The operator's GEC generates an ACD Record under ALE-061 (ACD_HUMAN_QUERY). The record carries the cap_profile_id and cap_profile_hash for the CAP Profile active during the inspection period, the gar_audit_endpoint for direct audit package access, and the ptd_endpoint for full Policy Transparency Disclosure. The inspector can confirm that stated prohibitions correspond to enforced Cedar policies (by hash), and that the audit trail for the period is complete and tamper-evident. The disclosure event itself is GAR-logged.
How this builds on existing work
KIA (Kernel Identity Attestation) provides the cryptographic kernel identity that makes ACD Records verifiable. Without KIA, an ACD Record's signature cannot be validated against a trusted attestation chain — any component could claim to be a compliant kernel. ACD uses KIA's XPID derivation for agent_xpid and KIA's signing key for gec_signature. KIA is the trust root; ACD is the compliance surface built on that root.
CAP and CAP-RRS produce and govern the CAP Profiles that ACD references in Layer 2. The cap_profile_id and cap_profile_hash in Layer 2 point to a signed artifact governed by CAP-RRS catalog versioning. ACD does not re-specify prohibition enforcement — it makes the enforcement posture externally queryable in a compact, signed form. The full prohibition corpus is always one ptd_endpoint query away.
RGP (Resource Governance Protocol) is the outbound complement to ACD's inbound verification. RGP lets agents discover what a resource provider offers. ACD lets resource providers verify the agent's compliance posture before granting what they offer. The acd_required: true field in RGP capability declarations is the trigger that initiates the ACD compliance handshake. Neither protocol is complete without the other.
Related work
Verifiable Credentials (W3C VC) provide a general mechanism for issuing and presenting cryptographically verifiable claims. ACD differs in that the ACD Record is produced by the enforcement kernel rather than by an external issuer, is specifically structured for compliance handshake use cases, and is directly bound to the kernel's operating CAP Profile and MJWT mandate. ACD is not a general credential format — it is a domain-specific compliance disclosure protocol for SOOS-governed agents.
OAuth 2.0 and OpenID Connect govern identity and authorization for API access. ACD complements these protocols: an ACD compliance handshake may occur alongside an OAuth authorization flow, but addresses a different layer. OAuth confirms that an agent has been granted permission by the resource owner. ACD confirms that the agent operates under constitutional prohibitions and governed law — the compliance posture the resource provider must verify independent of authorization grants.
No current IETF or W3C standard defines a machine-to-machine AI agent compliance handshake at the constitutional prohibition layer. ACD is the first.
Security
Key security properties: ACD Records are produced exclusively by the GEC — not by the LLM, not by any application layer component. Every record is KIA-signed using RFC 8785 canonicalization and RFC 7515 JWS. Every handshake is GAR-logged on the agent side. Every validity window is bounded (maximum 30 days, default 24 hours). GAR logs the SHA-256 hash of the record rather than the full record to satisfy data minimization requirements.
Incomplete disclosure attack: A GEC that produces technically-valid but substantively empty ACD Records (all tier counts zero, missing cap_profile_hash) is addressed by two defenses: the GEC MUST NOT produce records with absent REQUIRED Layer 2 fields, and resource providers MUST inspect Layer 2 content rather than validating signature only.
Spoofed ACD Record: All ACD transport is over TLS (RFC 8446). Resource providers MUST verify gec_signature against the KIA attestation chain published in the Party Registry — not against any other key source. The agent_xpid in the record MUST match the XPID of the kernel queried.
ACD Record replay: Resource providers MUST reject records where current time is after acd_validity_not_after. High-compliance deployments SHOULD use short validity windows (24 hours or less) and SHOULD bind ACD Records to the specific AEP session.
Formal analysis status: ACD-00 has not undergone formal security analysis. The KIA-signature and CSPRNG-based UUID generation requirements follow established cryptographic practice. Formal analysis is planned post-Vienna.
SOOS stack context
ACD sits at Layer 5 — Resource Access Governance. It depends on KIA (draft-sato-soos-kia-03) for kernel identity and signing, CAP (draft-sato-soos-cap-04) and CAP-RRS (draft-sato-soos-cap-rrs-02) for the CAP Profiles it references, AEP (draft-sato-soos-aep-02) for the session lifecycle within which it operates, MJWT (draft-sato-soos-mjwt-02) for the mandate JWT it binds, GAR (draft-sato-soos-gar-03) for audit logging, HEM (draft-sato-soos-hem-05) for escalation on validation failure, and RGP for the acd_required trigger. It is consumed by resource providers implementing the ACD compliance handshake. Related drafts: KIA · CAP · GAR · AEP · MJWT · RGP · KEE-1
Contribute
- File an issue on GitHub
- IETF Datatracker
- Related drafts: KIA · CAP · GAR · RGP
- Contact: tomsato@myauberge.jp