808 lines
26 KiB
Markdown
808 lines
26 KiB
Markdown
---
|
|
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.
|