c/ietf-draft-analyzer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
ietf-draft-analyzer/workspace/drafts/gap-analysis/draft-nennemann-agent-cross-domain-audit-00.md
Christian Nennemann 2506b6325a
Some checks failed
CI / test (3.11) (push) Failing after 1m37s
Details
CI / test (3.12) (push) Failing after 57s
Details
feat: add draft data, gap analysis report, and workspace config
2026-04-06 18:47:15 +02:00

26 KiB
Raw Permalink Blame History 

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

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

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:

{
  "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:

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

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:

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

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:

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

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:

{
  "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 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:

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

Per-Agent Resource Consumption Claims

Resource consumption is recorded as claims in the EAT payload under the "resource" key:

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

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:

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

Reference in New Issue View Git Blame Copy Permalink