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