]> Independent Researcher

ietf@nennemann.de

OPS NMOP cross-domain audit resource accounting agent workflows regulatory compliance billing 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 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.

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 :

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 and the Execution Context Token (ECT) defined in . 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 () Regulatory profile mapping for GDPR, SOX, and HIPAA () Audit trail stitching protocol for cross-domain correlation () Selective disclosure mechanisms for privacy-preserving audit () Resource metering model and consumption record format () Billing integration and settlement protocol ()

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. 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.

| Log| | | | B1 |->| Log| | | | C1 |->| Log| | | +------+ +--+-+ | | +------+ +--+-+ | | +------+ +--+-+ | | | | | | | | | | | +---------+ | | | +---------+ | | | +---------+ | | | |Reg. | | | | |Reg. | | | | |Reg. | | | | |Profile | | | | |Profile | | | | |Profile | | | | +---------+ | | | +---------+ | | | +---------+ | | +--------------+----+ +--------------+----+ +--------------+----+ | | | v v v +-----+-------------------------+-------------------------+----+ | Cross-Domain Audit Stitching Layer | | | | Boundary Crossing Records + Correlation Identifiers | +--------------------------------------------------------------+ ]]>

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 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 with the following claims:

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 .

xref:

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

Domain-Specific Extensions Each regulatory profile MAY define additional required claims. Domain-specific extensions are carried in a "domain_ext" object:

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

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:

Audit Trail Stitching

Cross-Domain Correlation Protocol When a workflow crosses a domain boundary, the following protocol ensures audit trail continuity: The source domain creates a boundary crossing record containing the last audit record's JTI and a newly generated boundary_id. The source domain signs the boundary crossing record and transmits it to the destination domain along with the agent handoff. The destination domain creates its first audit record with an xref object referencing the boundary_id and the source domain's last JTI. 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:

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) 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:

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: 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. Claims classified as "boundary" MUST be disclosed to the immediate destination domain but redacted for subsequent domains in the chain. Claims classified as "public" MUST be disclosed to all domains. 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

Metering Points Resource meters are placed at defined points in the agent execution pipeline: Task Ingress: Resources consumed receiving and parsing task inputs. Execution: Resources consumed during task execution proper. Tool Invocation: Resources consumed by each tool call within a task. Task Egress: Resources consumed producing and transmitting task outputs. 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:

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:

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:

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 ():

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 ():

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 . 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 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 : 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

Regulatory Profile Registry This document establishes a new "Agent Audit Regulatory Profiles" registry. The registration policy is Specification Required . 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

Resource Type Registry This document establishes a new "Agent Resource Types" registry. The registration policy is Specification Required . Initial registrations are listed in .

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Fraunhofer SIT Microsoft Research Microsoft Research ARM Traceability in supply chains is a growing security concern. While verifiable data structures have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility, interoperability between different transparency services, and compliance with various auditing procedures and regulatory requirements. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. European Parliament and Council

Acknowledgments The author thanks the participants of the NMOP working group for their feedback on agent management and operational challenges.