Cross-Domain Agent Audit Trails and Resource Accounting

3.2.1. 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 Section 3.3.¶

xref:

OPTIONAL. Cross-reference object for audit trail stitching. Present when this record follows a domain boundary crossing. See Section 3.4.¶

3.2.2. 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"
    }
  }
}

3.2.3. 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.¶

3.3.1. Profile Definitions

A regulatory profile is identified by a string of the form "{framework}-v{version}". This document defines the following initial profiles:¶

3.3.2. 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.¶

3.3.3. 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
  }
}

3.4.1. 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.¶

3.4.2. 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.¶

3.4.3. 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.¶

3.5.1. 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.¶

3.5.2. 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.¶

3.5.3. 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.¶

4.1.1. Resource Types

This document defines the following resource types for agent metering:¶

4.1.2. 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.¶

4.1.3. 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).¶

4.2.1. 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"
      }
    ]
  }
}

4.2.2. 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.¶

4.2.3. 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.¶

4.3.1. 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.¶

4.3.2. 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.¶

4.3.3. 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).¶