Internet-Draft | Agent Cross-Domain Audit | March 2026
Nennemann | Expires 7 September 2026 | [Page]

Workgroup:
  NMOP
Internet-Draft:
  draft-nennemann-agent-cross-domain-audit-00
Published:
  6 March 2026
Intended Status:
  Standards Track
Expires:
  7 September 2026
Author:
  C. Nennemann
  Independent Researcher

# Cross-Domain Agent Audit Trails and Resource Accounting

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

## Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 September 2026.¶

## Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

## 1. 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.¶

### 1.1. Scope

This document defines:¶

- Cross-domain audit record format extending EAT (Section 3.1)¶

- Regulatory profile mapping for GDPR, SOX, and HIPAA (Section 3.3)¶

- Audit trail stitching protocol for cross-domain correlation (Section 3.4)¶

- Selective disclosure mechanisms for privacy-preserving audit (Section 3.5)¶

- Resource metering model and consumption record format (Section 4.1)¶

- Billing integration and settlement protocol (Section 4.3)¶

## 2. 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 [RFC2119] [RFC8174] 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.¶

## 3. Cross-Domain Audit Trails

### 3.1. 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         |
             +--------------------------------------------------------------+

Figure 1: 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.¶

### 3.2. 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.¶

#### 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. Regulatory Profile Mapping

#### 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:¶

Table 1: Regulatory Profile Definitions
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

#### 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. Audit Trail Stitching

#### 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. Selective Disclosure

#### 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. Resource Accounting

### 4.1. Resource Metering Model

#### 4.1.1. Resource Types

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

Table 2: Resource Type Definitions
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

#### 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. Consumption Records

#### 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. Billing Integration

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

## 5. 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.¶

## 6. Security Considerations

### 6.1. 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.¶

### 6.2. 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.¶

### 6.3. 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.¶

### 6.4. 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.¶

## 7. IANA Considerations

### 7.1. JWT Claims Registration

This document requests registration of the following claims in the JSON Web Token Claims registry established by [RFC7519]:¶

Table 3: JWT Claims Registration
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

### 7.2. Regulatory Profile Registry

This document establishes a new "Agent Audit Regulatory Profiles" registry. The registration policy is Specification Required [RFC8126].¶

Initial registrations:¶

Table 4: Regulatory Profile Registry
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

### 7.3. Resource Type Registry

This document establishes a new "Agent Resource Types" registry. The registration policy is Specification Required [RFC8126].¶

Initial registrations are listed in Table 2.¶

## 8. References

### 8.1. Normative References

[I-D.nennemann-exec-audit]
  "Cross-Domain Execution Audit Tokens", n.d., <https://datatracker.ietf.org/doc/draft-nennemann-exec-audit/>.
[I-D.nennemann-wimse-ect]
  "Execution Context Tokens for Distributed Agentic Workflows", n.d., <https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/>.
[RFC2119]
  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7515]
  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7519]
  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8126]
  Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174]
  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9110]
  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

### 8.2. Informative References

[EU-AI-ACT]
  European Parliament and Council, "Regulation (EU) 2024/1689 (AI Act)", 2024, <https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.
[I-D.ietf-scitt-architecture]
  Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture-22, 10 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22>.
[I-D.nennemann-agent-gap-analysis]
  "Gap Analysis for Autonomous Agent Protocols", n.d., <https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/>.
[RFC9334]
  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[SD-JWT]
  "Selective Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-Draft, draft-ietf-oauth-selective-disclosure-jwt, 2024, <https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/>.

## Acknowledgments

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

## Author's Address