feat: add draft data, gap analysis report, and workspace config

workspace/drafts/gap-analysis/draft-nennemann-agent-cross-domain-audit-00.md

@@ -0,0 +1,807 @@
+---
+title: "Cross-Domain Agent Audit Trails and Resource Accounting"
+abbrev: "Agent Cross-Domain Audit"
+category: std
+docname: draft-nennemann-agent-cross-domain-audit-00
+submissiontype: IETF
+number:
+date:
+v: 3
+area: "OPS"
+workgroup: "NMOP"
+keyword:
+  - cross-domain audit
+  - resource accounting
+  - agent workflows
+  - regulatory compliance
+  - billing
+
+author:
+  -
+    fullname: Christian Nennemann
+    organization: Independent Researcher
+    email: ietf@nennemann.de
+
+normative:
+  RFC2119:
+  RFC8174:
+  RFC7519:
+  RFC7515:
+  RFC9110:
+  I-D.nennemann-wimse-ect:
+    title: "Execution Context Tokens for Distributed Agentic Workflows"
+    target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
+  I-D.nennemann-exec-audit:
+    title: "Cross-Domain Execution Audit Tokens"
+    target: https://datatracker.ietf.org/doc/draft-nennemann-exec-audit/
+
+informative:
+  I-D.nennemann-agent-gap-analysis:
+    title: "Gap Analysis for Autonomous Agent Protocols"
+    target: https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/
+  I-D.ietf-scitt-architecture:
+  RFC9334:
+  SD-JWT:
+    title: "Selective Disclosure for JWTs (SD-JWT)"
+    target: https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
+    seriesinfo:
+      Internet-Draft: draft-ietf-oauth-selective-disclosure-jwt
+    date: 2024
+  EU-AI-ACT:
+    title: "Regulation (EU) 2024/1689 (AI Act)"
+    target: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
+    date: 2024
+    author:
+      - org: European Parliament and Council
+
+--- abstract
+
+This document defines standardized formats and protocols for
+maintaining audit trails when autonomous agents operate across
+multiple administrative domains and organizations with divergent
+regulatory requirements.  It additionally specifies mechanisms for
+tracking, recording, and settling agent resource consumption
+across domain boundaries.
+
+The cross-domain audit trail format extends the Execution Audit
+Token (EAT) defined in {{I-D.nennemann-exec-audit}} with
+regulatory profile metadata, audit trail stitching identifiers,
+and selective disclosure controls.  The resource accounting
+framework introduces metering points, consumption records, and
+a settlement protocol for multi-domain agent deployments.
+
+--- middle
+
+# Introduction
+
+Autonomous agent workflows increasingly span multiple
+administrative domains, each subject to distinct regulatory
+regimes.  An agent operating in the European Union must satisfy
+GDPR data protection requirements; the same workflow may cross
+into a US domain governed by HIPAA for healthcare data or SOX
+for financial reporting.  Each domain maintains its own audit
+infrastructure, retention policies, and disclosure obligations.
+
+This document addresses two gaps identified in
+{{I-D.nennemann-agent-gap-analysis}}:
+
+Gap 6 -- Cross-Domain Audit Trails:
+: No standardized mechanism exists for maintaining coherent
+  audit trails when agent workflows cross organizational
+  boundaries with different regulatory requirements.  Existing
+  audit systems are domain-local and cannot correlate execution
+  records across trust boundaries without leaking regulated
+  information.
+
+Gap 9 -- Resource Accounting:
+: Agent workflows consume computational resources -- CPU cycles,
+  network bandwidth, storage, API calls, and large language
+  model token usage -- across multiple domains.  No standard
+  format exists for metering these resources, attributing
+  consumption to specific agents or tasks, and settling costs
+  across organizational boundaries.
+
+This document builds on the Execution Audit Token (EAT) format
+defined in {{I-D.nennemann-exec-audit}} and the Execution Context
+Token (ECT) defined in {{I-D.nennemann-wimse-ect}}.  It extends
+both with cross-domain audit claims and resource accounting
+fields while preserving backward compatibility.
+
+## Scope
+
+This document defines:
+
+- Cross-domain audit record format extending EAT
+  ({{audit-architecture}})
+- Regulatory profile mapping for GDPR, SOX, and HIPAA
+  ({{regulatory-profiles}})
+- Audit trail stitching protocol for cross-domain correlation
+  ({{audit-stitching}})
+- Selective disclosure mechanisms for privacy-preserving audit
+  ({{selective-disclosure}})
+- Resource metering model and consumption record format
+  ({{resource-metering}})
+- Billing integration and settlement protocol
+  ({{billing-integration}})
+
+# Terminology
+
+{::boilerplate bcp14-tagged}
+
+The following terms are used in this document:
+
+Audit Domain:
+: An administrative boundary within which a single set of audit
+  policies, retention requirements, and regulatory obligations
+  apply uniformly.
+
+Domain Boundary:
+: The point at which an agent workflow transitions from one audit
+  domain to another, triggering boundary crossing records and
+  potential selective disclosure.
+
+Regulatory Profile:
+: A machine-readable identifier specifying the regulatory
+  framework (e.g., GDPR, SOX, HIPAA) governing audit records
+  within an audit domain.
+
+Audit Record:
+: A single entry in the cross-domain audit trail, extending the
+  EAT format with domain-specific metadata and cross-reference
+  identifiers.
+
+Audit Stitching:
+: The process of correlating audit records across domain
+  boundaries to reconstruct end-to-end workflow execution
+  history without requiring full data disclosure.
+
+Selective Disclosure:
+: A mechanism allowing an audit record holder to reveal only
+  specific claims to a verifier while proving the integrity of
+  the complete record.
+
+Resource Meter:
+: A component that measures agent resource consumption at defined
+  metering points within the execution pipeline.
+
+Consumption Record:
+: A signed attestation of resource usage by an agent or task,
+  including resource type, quantity, and attribution metadata.
+
+Settlement:
+: The process of reconciling consumption records across domain
+  boundaries and resolving financial obligations between
+  organizations.
+
+# Cross-Domain Audit Trails
+
+## Audit Architecture {#audit-architecture}
+
+Cross-domain audit trails follow a federated architecture where
+each domain maintains sovereign control over its audit records
+while enabling end-to-end trail reconstruction through
+cryptographic stitching.
+
+~~~
++------------------+     +------------------+     +------------------+
+|   Domain A       |     |   Domain B       |     |   Domain C       |
+|  (GDPR)          |     |  (SOX)           |     |  (HIPAA)         |
+|                  |     |                  |     |                  |
+| +------+  +----+ |     | +------+  +----+ |     | +------+  +----+ |
+| |Agent | |Audit| |     | |Agent | |Audit| |     | |Agent | |Audit| |
+| |  A1  |->| Log| |     | |  B1  |->| Log| |     | |  C1  |->| Log| |
+| +------+  +--+-+ |     | +------+  +--+-+ |     | +------+  +--+-+ |
+|              |    |     |              |    |     |              |    |
+| +---------+  |    |     | +---------+  |    |     | +---------+  |    |
+| |Reg.     |  |    |     | |Reg.     |  |    |     | |Reg.     |  |    |
+| |Profile  |  |    |     | |Profile  |  |    |     | |Profile  |  |    |
+| +---------+  |    |     | +---------+  |    |     | +---------+  |    |
++--------------+----+     +--------------+----+     +--------------+----+
+               |                         |                         |
+               v                         v                         v
+         +-----+-------------------------+-------------------------+----+
+         |              Cross-Domain Audit Stitching Layer              |
+         |                                                              |
+         |  Boundary Crossing Records + Correlation Identifiers         |
+         +--------------------------------------------------------------+
+~~~
+{: #fig-audit-arch title="Cross-Domain Audit Architecture"}
+
+Each domain operates independently with its own audit log and
+regulatory profile.  The stitching layer connects audit records
+across boundaries using cryptographic cross-references without
+requiring domains to share raw audit data.
+
+## Audit Record Format {#audit-record-format}
+
+The cross-domain audit record extends the EAT payload defined
+in {{I-D.nennemann-exec-audit}} with additional claims for
+domain identification, regulatory context, and cross-referencing.
+
+### Base Audit Record Structure
+
+The base audit record is a JSON object carried as the payload of
+a JWS {{RFC7515}} with the following claims:
+
+~~~json
+{
+  "iss": "https://domain-a.example.com/audit",
+  "sub": "agent:a1:task:12345",
+  "iat": 1700000000,
+  "jti": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
+  "eat_ref": "urn:uuid:a1b2c3d4-e5f6-7890-abcd-ef1234567890",
+  "aud_domain": "domain-a.example.com",
+  "reg_profile": "gdpr-v1",
+  "xref": {
+    "prev_domain": "domain-b.example.com",
+    "prev_jti": "urn:uuid:12345678-abcd-ef01-2345-678901234567",
+    "boundary_id": "urn:uuid:bnd-98765432-dcba-10fe-5432-109876543210"
+  },
+  "task_desc": "Process customer data enrichment",
+  "inputs_hash": "sha256:abc123...",
+  "outputs_hash": "sha256:def456...",
+  "assurance_level": "L2"
+}
+~~~
+
+The claims are defined as follows:
+
+eat_ref:
+: REQUIRED.  A reference to the corresponding Execution Audit
+  Token for this task, enabling correlation between the audit
+  record and the execution context.
+
+aud_domain:
+: REQUIRED.  The fully qualified domain name of the audit domain
+  that produced this record.
+
+reg_profile:
+: REQUIRED.  The regulatory profile identifier governing this
+  audit record.  See {{regulatory-profiles}}.
+
+xref:
+: OPTIONAL.  Cross-reference object for audit trail stitching.
+  Present when this record follows a domain boundary crossing.
+  See {{audit-stitching}}.
+
+### Domain-Specific Extensions
+
+Each regulatory profile MAY define additional required claims.
+Domain-specific extensions are carried in a "domain_ext" object:
+
+~~~json
+{
+  "domain_ext": {
+    "gdpr": {
+      "data_subject_category": "customer",
+      "processing_purpose": "enrichment",
+      "legal_basis": "legitimate_interest",
+      "retention_days": 730,
+      "dpo_contact": "dpo@domain-a.example.com"
+    }
+  }
+}
+~~~
+
+### Cross-Reference Identifiers
+
+Cross-reference identifiers enable trail stitching without
+requiring access to the full audit records of other domains:
+
+boundary_id:
+: A globally unique identifier assigned at the domain boundary
+  crossing point.  Both the outgoing record in the source domain
+  and the incoming record in the destination domain carry the
+  same boundary_id.
+
+prev_jti:
+: The JTI of the last audit record in the preceding domain.
+  This enables sequential chain verification.
+
+prev_domain:
+: The audit domain identifier of the preceding domain.
+
+## Regulatory Profile Mapping {#regulatory-profiles}
+
+### Profile Definitions
+
+A regulatory profile is identified by a string of the form
+"{framework}-v{version}".  This document defines the following
+initial profiles:
+
+| Profile ID  | Framework | Required Claims | Retention |
+|:------------|:----------|:----------------|:----------|
+| gdpr-v1     | EU GDPR   | data_subject_category, processing_purpose, legal_basis, retention_days | Per purpose |
+| sox-v1      | US SOX    | control_objective, control_id, evidence_class, attestor | 7 years |
+| hipaa-v1    | US HIPAA  | phi_category, access_purpose, minimum_necessary, covered_entity | 6 years |
+{: #tab-profiles title="Regulatory Profile Definitions"}
+
+### Compliance Field Mapping
+
+Each profile maps to a set of required and optional claims in the
+"domain_ext" object.  An audit record MUST include all required
+claims for its declared regulatory profile.  A verifier MUST
+reject records missing required claims.
+
+GDPR Profile (gdpr-v1):
+: REQUIRED claims: data_subject_category, processing_purpose,
+  legal_basis, retention_days.
+  OPTIONAL claims: dpo_contact, cross_border_transfer,
+  data_categories, recipients.
+
+SOX Profile (sox-v1):
+: REQUIRED claims: control_objective, control_id, evidence_class,
+  attestor.
+  OPTIONAL claims: deficiency_flag, management_response,
+  test_procedure.
+
+HIPAA Profile (hipaa-v1):
+: REQUIRED claims: phi_category, access_purpose,
+  minimum_necessary, covered_entity.
+  OPTIONAL claims: business_associate, disclosure_authorization,
+  breach_risk_assessment.
+
+### Regulatory Metadata Claims
+
+Regulatory metadata is carried as claims in the EAT payload
+under the "reg_meta" key:
+
+~~~json
+{
+  "reg_meta": {
+    "profile": "gdpr-v1",
+    "jurisdiction": "EU",
+    "supervisory_authority": "de-bfdi",
+    "cross_border": true,
+    "adequacy_decision": "eu-us-dpf",
+    "retention_expiry": 1763078400
+  }
+}
+~~~
+
+## Audit Trail Stitching {#audit-stitching}
+
+### Cross-Domain Correlation Protocol
+
+When a workflow crosses a domain boundary, the following protocol
+ensures audit trail continuity:
+
+1. The source domain creates a boundary crossing record containing
+   the last audit record's JTI and a newly generated boundary_id.
+
+2. The source domain signs the boundary crossing record and
+   transmits it to the destination domain along with the agent
+   handoff.
+
+3. The destination domain creates its first audit record with
+   an xref object referencing the boundary_id and the source
+   domain's last JTI.
+
+4. Both domains independently log the boundary crossing record
+   in their respective audit ledgers.
+
+### Boundary Crossing Records
+
+A boundary crossing record is a JWS-signed JSON object:
+
+~~~json
+{
+  "type": "boundary_crossing",
+  "boundary_id": "urn:uuid:bnd-98765432-dcba-10fe-5432-109876543210",
+  "source_domain": "domain-a.example.com",
+  "dest_domain": "domain-b.example.com",
+  "source_last_jti": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
+  "crossing_time": 1700000100,
+  "workflow_id": "urn:uuid:wf-11111111-2222-3333-4444-555555555555",
+  "source_reg_profile": "gdpr-v1",
+  "dest_reg_profile": "sox-v1",
+  "disclosed_claims": ["task_desc", "inputs_hash", "outputs_hash"],
+  "redacted_claims": ["data_subject_category", "processing_purpose"]
+}
+~~~
+
+The "disclosed_claims" and "redacted_claims" arrays enumerate
+which claims from the source domain's audit record are visible
+to the destination domain and which are withheld for privacy.
+
+### Partial Trail Assembly
+
+An auditor with access to multiple domains can reconstruct the
+full workflow trail by following the chain of boundary_id
+references.  When an auditor lacks access to a particular domain,
+the trail contains a gap that can be verified structurally
+(the boundary crossing records on either side reference the same
+boundary_id) without revealing the content of the missing
+domain's records.
+
+This allows privacy-preserving end-to-end audit where each domain
+proves its segment of the trail without exposing regulated data
+to unauthorized parties.
+
+## Selective Disclosure {#selective-disclosure}
+
+### Using SD-JWT Concepts for Audit Records
+
+Cross-domain audit records MAY use Selective Disclosure JWT
+(SD-JWT) {{SD-JWT}} mechanisms to enable fine-grained claim
+disclosure.  When an audit record is issued, the issuer creates
+an SD-JWT where each claim can be independently disclosed or
+withheld.
+
+An SD-JWT audit record replaces direct claims with hashed
+disclosures:
+
+~~~json
+{
+  "iss": "https://domain-a.example.com/audit",
+  "aud_domain": "domain-a.example.com",
+  "reg_profile": "gdpr-v1",
+  "_sd": [
+    "WyJ...base64url-encoded disclosure hash..."
+  ],
+  "_sd_alg": "sha-256"
+}
+~~~
+
+Individual claims are disclosed by providing the corresponding
+disclosure values alongside the SD-JWT.
+
+### Per-Domain Visibility Controls
+
+Each audit domain declares a visibility policy specifying which
+claims are:
+
+- Public: Disclosed to all domains in the workflow trail.
+- Boundary: Disclosed only to the immediate upstream and
+  downstream domains.
+- Private: Never disclosed outside the originating domain.
+
+The visibility policy is declared in the regulatory profile
+and enforced at each domain boundary crossing.
+
+### Redaction and Minimization Rules
+
+When an audit record crosses a domain boundary, the following
+rules apply:
+
+1. Claims classified as "private" MUST be redacted using SD-JWT
+   disclosures.  The destination domain receives proof that the
+   claims exist but cannot read their values.
+
+2. Claims classified as "boundary" MUST be disclosed to the
+   immediate destination domain but redacted for subsequent
+   domains in the chain.
+
+3. Claims classified as "public" MUST be disclosed to all
+   domains.
+
+4. The minimum set of public claims required for trail stitching
+   is: jti, boundary_id, aud_domain, and crossing_time.
+
+# Resource Accounting
+
+## Resource Metering Model {#resource-metering}
+
+### Resource Types
+
+This document defines the following resource types for agent
+metering:
+
+| Resource Type | Unit | Description |
+|:--------------|:-----|:------------|
+| compute       | cpu-ms | CPU time in milliseconds |
+| memory        | byte-s | Memory usage in byte-seconds |
+| network_egress| bytes  | Outbound network transfer |
+| network_ingress| bytes | Inbound network transfer |
+| storage       | byte-s | Persistent storage in byte-seconds |
+| api_calls     | count  | External API invocations |
+| llm_tokens    | count  | Large language model tokens consumed |
+| gpu_compute   | gpu-ms | GPU time in milliseconds |
+{: #tab-resources title="Resource Type Definitions"}
+
+### Metering Points
+
+Resource meters are placed at defined points in the agent
+execution pipeline:
+
+1. Task Ingress: Resources consumed receiving and parsing task
+   inputs.
+2. Execution: Resources consumed during task execution proper.
+3. Tool Invocation: Resources consumed by each tool call within
+   a task.
+4. Task Egress: Resources consumed producing and transmitting
+   task outputs.
+5. Audit Overhead: Resources consumed generating and transmitting
+   audit records themselves.
+
+Each metering point produces a meter reading that is included
+in the task's consumption record.
+
+### Meter Reading Format
+
+A meter reading is a JSON object:
+
+~~~json
+{
+  "meter_point": "execution",
+  "resource_type": "llm_tokens",
+  "quantity": 4096,
+  "unit": "count",
+  "start_time": 1700000000,
+  "end_time": 1700000005,
+  "confidence": "measured"
+}
+~~~
+
+The "confidence" field indicates whether the reading is
+"measured" (exact instrumentation), "estimated" (statistical
+sampling), or "allocated" (apportioned from a shared pool).
+
+## Consumption Records {#consumption-records}
+
+### Per-Agent Resource Consumption Claims
+
+Resource consumption is recorded as claims in the EAT payload
+under the "resource" key:
+
+~~~json
+{
+  "resource": {
+    "agent_id": "spiffe://domain-a.example.com/agent/a1",
+    "task_id": "urn:uuid:a1b2c3d4-e5f6-7890-abcd-ef1234567890",
+    "domain": "domain-a.example.com",
+    "period": {
+      "start": 1700000000,
+      "end": 1700000010
+    },
+    "meters": [
+      {
+        "meter_point": "execution",
+        "resource_type": "compute",
+        "quantity": 2500,
+        "unit": "cpu-ms",
+        "confidence": "measured"
+      },
+      {
+        "meter_point": "execution",
+        "resource_type": "llm_tokens",
+        "quantity": 4096,
+        "unit": "count",
+        "confidence": "measured"
+      },
+      {
+        "meter_point": "tool_invocation",
+        "resource_type": "api_calls",
+        "quantity": 3,
+        "unit": "count",
+        "confidence": "measured"
+      }
+    ]
+  }
+}
+~~~
+
+### Aggregation Across DAG Nodes
+
+When a workflow DAG spans multiple tasks, consumption records
+can be aggregated to produce a workflow-level resource summary.
+The aggregation MUST:
+
+- Sum quantities of the same resource type and unit across all
+  DAG nodes within a domain.
+- Maintain per-task granularity for dispute resolution.
+- Record the aggregation method ("sum", "max", "weighted") for
+  each resource type.
+
+### Multi-Tenant Isolation
+
+In shared infrastructure deployments, resource meters MUST
+provide tenant isolation guarantees:
+
+- Each agent's resource consumption MUST be independently
+  metered.
+- Shared resources (e.g., shared GPU pools) MUST use the
+  "allocated" confidence level and document the allocation
+  method.
+- Consumption records MUST NOT leak information about other
+  tenants' resource usage.
+
+## Billing Integration {#billing-integration}
+
+### Settlement Protocol Overview
+
+Settlement between domains follows a three-phase protocol:
+
+Phase 1 -- Reporting:
+: Each domain produces a signed usage report summarizing
+  consumption records for a billing period.  The report is
+  signed using the domain's audit signing key.
+
+Phase 2 -- Reconciliation:
+: Participating domains exchange usage reports and verify that
+  boundary crossing records match.  Discrepancies are flagged
+  for manual review.
+
+Phase 3 -- Settlement:
+: Reconciled usage is converted to monetary amounts using
+  pre-agreed rate cards.  Settlement records are logged in
+  each domain's audit ledger.
+
+### Usage Report Format
+
+A usage report is a JWS-signed JSON object:
+
+~~~json
+{
+  "type": "usage_report",
+  "reporter_domain": "domain-a.example.com",
+  "billing_period": {
+    "start": 1700000000,
+    "end": 1702592000
+  },
+  "counterparty_domain": "domain-b.example.com",
+  "summary": [
+    {
+      "resource_type": "compute",
+      "total_quantity": 15000000,
+      "unit": "cpu-ms",
+      "task_count": 1250
+    },
+    {
+      "resource_type": "llm_tokens",
+      "total_quantity": 5242880,
+      "unit": "count",
+      "task_count": 1250
+    }
+  ],
+  "detail_hash": "sha256:fedcba987654...",
+  "rate_card_ref": "urn:uuid:rc-aabbccdd-1122-3344-5566-778899001122"
+}
+~~~
+
+The "detail_hash" is a hash of the full set of per-task
+consumption records, enabling the counterparty to request and
+verify individual records during dispute resolution.
+
+### Fair-Use Enforcement Mechanisms
+
+Domains MAY enforce fair-use policies on agent resource
+consumption:
+
+- Rate Limiting: Domains MAY impose per-agent or per-workflow
+  rate limits on resource types.  Rate limit policies SHOULD
+  be communicated in the boundary crossing record.
+
+- Budget Caps: Workflows MAY carry a resource budget in the ECT
+  that specifies maximum consumption per resource type.  Agents
+  MUST NOT exceed the declared budget without obtaining a revised
+  ECT.
+
+- Anomaly Detection: Domains SHOULD monitor consumption patterns
+  and flag anomalous usage (e.g., token consumption 10x above
+  the workflow's declared budget).
+
+# Integration with ECT and Exec-Audit
+
+The cross-domain audit and resource accounting claims defined in
+this document extend the existing token formats as follows:
+
+ECT Extensions ({{I-D.nennemann-wimse-ect}}):
+: The ECT payload is extended with a "resource_budget" claim
+  specifying per-resource-type consumption limits for the
+  workflow.  The ECT MAY also carry a "reg_profiles" array
+  listing the regulatory profiles that the workflow is expected
+  to traverse.
+
+EAT Extensions ({{I-D.nennemann-exec-audit}}):
+: The EAT payload is extended with the "aud_domain", "reg_profile",
+  "reg_meta", "xref", "domain_ext", and "resource" claims defined
+  in this document.  These claims are OPTIONAL for single-domain
+  deployments and REQUIRED for cross-domain workflows.
+
+Backward Compatibility:
+: Existing ECT and EAT processors that do not recognize the new
+  claims MUST ignore them per standard JWT processing rules
+  {{RFC7519}}.  Cross-domain audit functionality degrades
+  gracefully: single-domain deployments continue to function
+  without modification.
+
+# Security Considerations
+
+## Audit Trail Tampering Across Domains
+
+Because each domain signs its own audit records independently,
+a compromised domain can fabricate or alter its segment of the
+audit trail.  Mitigations include:
+
+- Requiring Level 3 assurance (ledger-anchored EATs) for
+  cross-domain workflows in regulated environments.
+- Cross-domain ledger anchoring as defined in
+  {{I-D.nennemann-exec-audit}} to detect tampering after the
+  fact.
+- Independent third-party audit of boundary crossing records.
+
+## Resource Metering Fraud
+
+A malicious domain could under-report resource consumption to
+reduce settlement obligations or over-report to inflate charges.
+Mitigations include:
+
+- Bilateral verification of boundary crossing records, which
+  constrain the plausible range of resource consumption.
+- Statistical sampling and spot-checking of consumption records
+  against actual infrastructure metrics.
+- Requiring "measured" confidence level for high-value resource
+  types and rejecting "estimated" readings above a threshold.
+
+## Privacy Leakage Through Audit Correlation
+
+Even with selective disclosure, the structure of the audit trail
+(timing, frequency, and pattern of boundary crossings) can leak
+information about the nature of the workflow.  Mitigations
+include:
+
+- Batching boundary crossing records to obscure individual
+  workflow timing.
+- Using domain-specific pseudonymous identifiers in cross-
+  references rather than globally unique agent identifiers.
+- Minimizing the set of public claims to the structural minimum
+  required for trail stitching.
+
+## Selective Disclosure Attacks
+
+An adversary with access to multiple boundary crossing records
+could attempt to correlate redacted claims across domains.
+SD-JWT provides unlinkability guarantees when fresh salts are
+used for each disclosure.  Implementations MUST use
+cryptographically random salts of at least 128 bits for each
+SD-JWT disclosure.
+
+# IANA Considerations
+
+## JWT Claims Registration
+
+This document requests registration of the following claims in
+the JSON Web Token Claims registry established by {{RFC7519}}:
+
+| Claim Name   | Description | Reference |
+|:-------------|:------------|:----------|
+| aud_domain   | Audit domain identifier | This document |
+| reg_profile  | Regulatory profile identifier | This document |
+| reg_meta     | Regulatory metadata object | This document |
+| xref         | Cross-domain reference object | This document |
+| domain_ext   | Domain-specific extension claims | This document |
+| resource     | Resource consumption record | This document |
+| resource_budget | Resource budget limits | This document |
+{: #tab-claims title="JWT Claims Registration"}
+
+## Regulatory Profile Registry
+
+This document establishes a new "Agent Audit Regulatory Profiles"
+registry.  The registration policy is Specification Required
+{{!RFC8126}}.
+
+Initial registrations:
+
+| Profile ID | Framework | Reference |
+|:-----------|:----------|:----------|
+| gdpr-v1    | EU General Data Protection Regulation | This document |
+| sox-v1     | US Sarbanes-Oxley Act | This document |
+| hipaa-v1   | US Health Insurance Portability and Accountability Act | This document |
+{: #tab-reg-profiles title="Regulatory Profile Registry"}
+
+## Resource Type Registry
+
+This document establishes a new "Agent Resource Types" registry.
+The registration policy is Specification Required {{!RFC8126}}.
+
+Initial registrations are listed in {{tab-resources}}.
+
+--- back
+
+# Acknowledgments
+{:numbered="false"}
+
+The author thanks the participants of the NMOP working group
+for their feedback on agent management and operational
+challenges.