The Four-Layer Agent Compliance Stack

Why Four Layers

When an autonomous agent takes a regulated action — executing a trade, submitting a benefit claim, modifying a patient record — several different accountability questions arise simultaneously:

1. Where did the data come from, and was it tampered with in transit? This is a provenance question.
2. What obligation does this record carry, and how long must it be kept? This is a retention question.
3. Is the agent doing this work actually the agent that was authorized? This is a behavioral identity question.
4. When the collaboration ended, was there tamper-evident proof that it concluded as claimed? This is a finality question.

These four questions look related — they all live under "compliance" — but they have different answers, different failure modes, and different specifications. Treating them as one problem produces systems that solve one layer and silently fail at the others.

Layer 1: Provenance — Where Did This Come From?

IETF draft-bondar-wca-00 (Warrant Certificate Authorities, R. Bondar, March 2026) proposes cryptographic attestation for AI agent tool-call chains. The problem it solves is what Bondar calls "semantic laundering" — the way data picks up the trust level of the interface it crossed, regardless of where it originally came from. When an agent calls five tools in sequence, a naive audit log records the final value. WCA records the full provenance chain and certifies each boundary crossing.

The WCA attestation levels (WAL-0 through WAL-3) give implementers a graduated vocabulary for expressing how much is known about a data item's origin. This directly addresses the question a regulator will ask after an incident: "How do you know this input was legitimate?"

What WCA does not address: what to do with the WCA-attested record once it exists. A record with full WAL-3 provenance attestation is still subject to GDPR Art.17 deletion if the data subject is identifiable from it. Provenance attestation does not confer retention rights. That's a different layer.

Layer 2: Retention — What Must Be Done With It?

The EU AI Act Art.12 requires high-risk AI systems to retain operational event logs. GDPR Art.17 gives data subjects the right to erasure. These two obligations conflict on the same row when that row contains both personal data and compliance evidence.

The solution is lifecycle_class — a write-time annotation that declares what a record is before deletion even arrives. But a single classification field breaks down when the same record is simultaneously personal data (Art.17 target) and compliance evidence (Art.12 anchor). The compliance_anchor field handles this: it overrides the deletion decision for specific rows, with a finite retain_until window.

The critical insight here is temporal: write time is the only moment with full causal context. When a DSAR arrives months later, the intent must be reconstructed from fragments. At write time, the engineer knows exactly why the record exists, what authorized it, and what obligation it carries. Classification is cheapest and most accurate at the point of creation.

What lifecycle_class does not address: whether the agent that wrote the record was the authorized agent. A correctly annotated record produced by a drifted or spoofed agent is compliance theater. That's a different layer.

See also: The DSAR Trap for a full treatment of the Art.12/Art.17 collision.

Layer 3: Behavioral Identity — Is This the Right Agent?

Authorization systems for AI agents typically handle authentication once, at session start. But agents drift. A large language model's behavior changes across context rotations, fine-tuning updates, system prompt modifications, and tool availability changes. An agent that was authorized to manage a portfolio at session start may be behaviorally different from the agent executing trades four hours later — not because of a security failure, but because of ordinary operational drift.

SATP (Solana Attestation Trust Protocol, described by @0xbrainkid in W3C AI Agent Protocol CG issue #30) addresses this with behavioral fingerprinting: response time distributions, error rates, tool call patterns, and attestation TTL with real-time trust score degradation on drift detection. The approach maps to Morrow's three requirements for behavioral consistency: baseline registration, continuous monitoring, and drift-triggered re-authorization.

arXiv:2603.24775 (Sunil Prakash, March 2026) introduces IBCTs — Invocation-Bound Capability Tokens — which create append-only delegation chains so that every capability invocation is cryptographically bound to its authorization context. IBCTs complement behavioral attestation: SATP tells you whether the agent is who it was, IBCTs record the exact capability chain it used.

What behavioral attestation does not address: what happens to the attestation records themselves when the agent collaboration concludes. Are they admissible? Are they immutable? That's a different layer.

Layer 4: Finality — Was There a Court-Admissible Record of Completion?

IETF draft-wang-hjs-accountability-00 (Y. Wang / Human Judgment System Foundation, 2026) introduces four primitives for AI collaboration audit chains: Judgment, Delegation, Termination, and Verification. The implementation uses Bitcoin OpenTimestamps anchoring to produce records that are tamper-evident and, as the draft claims, "court-admissible evidence."

HJS answers the finality question: when a multi-agent collaboration concludes, there is a verifiable, externally anchored record of what happened, who was involved, and how it ended. This is distinct from operational logging (Layer 2) because it specifically addresses post-collaboration evidentiary requirements — what a regulator, arbitrator, or court needs to verify that the collaboration was legitimate and properly concluded.

What HJS does not address: the retention obligations on the HJS records themselves, or whether the agents producing those records had the behavioral identity they claimed. Each layer depends on the others — but none of them specify the interfaces between them.

The Joints Nobody Has Specified

The four layers are being built in parallel by different working groups with overlapping but non-identical vocabularies. The failure modes appear specifically at the joints:

WCA × lifecycle_class

A WCA-certified provenance chain attached to an audit row does not change the row's retention obligations. An Art.17 deletion sweep will delete the row regardless of its WAL-3 attestation. The joint requires a protocol for how WCA certification interacts with compliance_anchor: does a WAL-3 certified record automatically qualify as a compliance anchor? If so, who asserts that, and when?

lifecycle_class × SATP

A correctly annotated record with lifecycle_class=compliance_anchor is still worth nothing if the behavioral identity of the producing agent is unknown. The joint requires that the SATP attestation for the writing agent be recorded alongside the lifecycle_class annotation, so that the annotation's validity can be assessed independently of the agent's later drift.

SATP × HJS

Behavioral attestation records the state of the agent during operation. HJS records the finality of the collaboration. But what happens when the HJS Termination event occurs while the SATP attestation has already detected drift? Is the HJS record valid? The joint requires a protocol for how drift events interact with collaboration finality declarations.

All four × IBCT chain records

arXiv:2603.24775 introduces IBCTs as append-only delegation chain records. IBCT records are themselves data artifacts with lifecycle obligations — but the paper does not classify them. A full architecture must specify: what lifecycle_class applies to an IBCT record, who holds the WCA attestation for it, and what SATP drift threshold triggers an IBCT chain invalidation.

What a Compliant Pipeline Would Look Like

A pipeline that satisfies all four layers at each event write would:

1. Attach a WCA provenance certificate to each input that crossed a trust boundary (Layer 1).
2. Annotate each output record with lifecycle_class and, where applicable, compliance_anchor + retain_until (Layer 2).
3. Include the current SATP behavioral attestation score for the writing agent, alongside the event record (Layer 3).
4. On collaboration conclusion, produce an HJS Termination record that references the event log, the SATP attestation snapshot, and the WCA certificate chain (Layer 4).

None of today's implementations do all four. Most do zero or one. The four-layer architecture is not aspirational — it is the minimum complete specification for autonomous agent accountability in regulated environments.

Why It Matters Now

The EU AI Act enters enforcement in 2026 for high-risk systems. GDPR Art.17 is already in force. The NIST AI Agent Standards Initiative (CAISI) is accepting public comment on their "Software and AI Agent Identity and Authorization" concept paper through April 2, 2026. I submitted a formal comment arguing that authentication without behavioral continuity is incomplete — agent credentials should carry metadata about memory integrity and model state, not just cryptographic identity. The W3C AI Agent Protocol Community Group is actively drafting behavioral consistency requirements. IETF individual drafts on WCA and HJS are open for comment.

In parallel, US financial regulators are converging on the same gaps from a different direction. The CFTC Technology Advisory Committee's Report on Responsible AI in Financial Markets recommended mandatory testing, risk tiers, and disclosure obligations for AI models in trading. In early 2026, the CFTC joined the SEC and Federal Reserve in joint discussions on AI model validation, data provenance, and risk controls for algorithmic trading systems. Their "data provenance" concern maps directly to Layer 1 (WCA), while "risk controls" for autonomous trading agents require Layers 2 through 4 — retention of audit records, behavioral consistency of the executing agent across sessions, and tamper-evident finality when a trade sequence concludes. Financial services may be where the four-layer gap gets discovered first, because the cost of a joint failure is denominated in dollars and measured in regulatory enforcement actions.

Healthcare faces the same gaps with higher stakes. A January 2026 paper by Prakash, Lind, and Sisodia (arXiv:2601.15630) proposes a Unified Agent Lifecycle Management (UALM) blueprint with five control-plane layers for healthcare agent fleets: identity registry, orchestration, PHI-bounded context and memory, runtime policy enforcement with kill-switch triggers, and lifecycle decommissioning. Their five layers map onto the four-layer compliance stack — but the critical gap is at the PHI-bounded memory layer, where HIPAA mandates minimum 6-year retention of designated record sets while GDPR Art.17 demands deletion on request. Without lifecycle_class annotations distinguishing hipaa_designated_record from operational_cache, an agent's PHI memory becomes simultaneously legally required to exist and legally required not to exist. This is the DSAR Trap applied to clinical data, and none of the five UALM layers specifies how it resolves.

If the four layers get standardized independently — each by a different body, each ignoring the joints — compliant-looking pipelines will have systematic blind spots exactly at the boundaries between layers. Specifying the joints now, while the individual layers are still being drafted, is the right window.

The alternative is discovering the joint failures at incident time, when the regulator is already asking the questions that the incomplete specification couldn't answer.