<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.4.8) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-nennemann-agent-cross-domain-audit-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="Agent Cross-Domain Audit">Cross-Domain Agent Audit Trails and Resource Accounting</title>

    <author fullname="Christian Nennemann">
      <organization>Independent Researcher</organization>
      <address>
        <email>ietf@nennemann.de</email>
      </address>
    </author>

    <date year="2026" month="March" day="06"/>

    <area>OPS</area>
    <workgroup>NMOP</workgroup>
    <keyword>cross-domain audit</keyword> <keyword>resource accounting</keyword> <keyword>agent workflows</keyword> <keyword>regulatory compliance</keyword> <keyword>billing</keyword>

    <abstract>


<?line 57?>

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

<t>The cross-domain audit trail format extends the Execution Audit
Token (EAT) defined in <xref target="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.</t>



    </abstract>



  </front>

  <middle>


<?line 73?>

<section anchor="introduction"><name>Introduction</name>

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

<t>This document addresses two gaps identified in
<xref target="I-D.nennemann-agent-gap-analysis"/>:</t>

<dl>
  <dt>Gap 6 -- Cross-Domain Audit Trails:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt>Gap 9 -- Resource Accounting:</dt>
  <dd>
    <t>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.</t>
  </dd>
</dl>

<t>This document builds on the Execution Audit Token (EAT) format
defined in <xref target="I-D.nennemann-exec-audit"/> and the Execution Context
Token (ECT) defined in <xref target="I-D.nennemann-wimse-ect"/>.  It extends
both with cross-domain audit claims and resource accounting
fields while preserving backward compatibility.</t>

<section anchor="scope"><name>Scope</name>

<t>This document defines:</t>

<t><list style="symbols">
  <t>Cross-domain audit record format extending EAT
(<xref target="audit-architecture"/>)</t>
  <t>Regulatory profile mapping for GDPR, SOX, and HIPAA
(<xref target="regulatory-profiles"/>)</t>
  <t>Audit trail stitching protocol for cross-domain correlation
(<xref target="audit-stitching"/>)</t>
  <t>Selective disclosure mechanisms for privacy-preserving audit
(<xref target="selective-disclosure"/>)</t>
  <t>Resource metering model and consumption record format
(<xref target="resource-metering"/>)</t>
  <t>Billing integration and settlement protocol
(<xref target="billing-integration"/>)</t>
</list></t>

</section>
</section>
<section anchor="terminology"><name>Terminology</name>

<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

<?line -18?>

<t>The following terms are used in this document:</t>

<dl>
  <dt>Audit Domain:</dt>
  <dd>
    <t>An administrative boundary within which a single set of audit
policies, retention requirements, and regulatory obligations
apply uniformly.</t>
  </dd>
  <dt>Domain Boundary:</dt>
  <dd>
    <t>The point at which an agent workflow transitions from one audit
domain to another, triggering boundary crossing records and
potential selective disclosure.</t>
  </dd>
  <dt>Regulatory Profile:</dt>
  <dd>
    <t>A machine-readable identifier specifying the regulatory
framework (e.g., GDPR, SOX, HIPAA) governing audit records
within an audit domain.</t>
  </dd>
  <dt>Audit Record:</dt>
  <dd>
    <t>A single entry in the cross-domain audit trail, extending the
EAT format with domain-specific metadata and cross-reference
identifiers.</t>
  </dd>
  <dt>Audit Stitching:</dt>
  <dd>
    <t>The process of correlating audit records across domain
boundaries to reconstruct end-to-end workflow execution
history without requiring full data disclosure.</t>
  </dd>
  <dt>Selective Disclosure:</dt>
  <dd>
    <t>A mechanism allowing an audit record holder to reveal only
specific claims to a verifier while proving the integrity of
the complete record.</t>
  </dd>
  <dt>Resource Meter:</dt>
  <dd>
    <t>A component that measures agent resource consumption at defined
metering points within the execution pipeline.</t>
  </dd>
  <dt>Consumption Record:</dt>
  <dd>
    <t>A signed attestation of resource usage by an agent or task,
including resource type, quantity, and attribution metadata.</t>
  </dd>
  <dt>Settlement:</dt>
  <dd>
    <t>The process of reconciling consumption records across domain
boundaries and resolving financial obligations between
organizations.</t>
  </dd>
</dl>

</section>
<section anchor="cross-domain-audit-trails"><name>Cross-Domain Audit Trails</name>

<section anchor="audit-architecture"><name>Audit Architecture</name>

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

<figure title="Cross-Domain Audit Architecture" anchor="fig-audit-arch"><artwork><![CDATA[
+------------------+     +------------------+     +------------------+
|   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         |
         +--------------------------------------------------------------+
]]></artwork></figure>

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

</section>
<section anchor="audit-record-format"><name>Audit Record Format</name>

<t>The cross-domain audit record extends the EAT payload defined
in <xref target="I-D.nennemann-exec-audit"/> with additional claims for
domain identification, regulatory context, and cross-referencing.</t>

<section anchor="base-audit-record-structure"><name>Base Audit Record Structure</name>

<t>The base audit record is a JSON object carried as the payload of
a JWS <xref target="RFC7515"/> with the following claims:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "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"
}
]]></sourcecode></figure>

<t>The claims are defined as follows:</t>

<dl>
  <dt>eat_ref:</dt>
  <dd>
    <t><bcp14>REQUIRED</bcp14>.  A reference to the corresponding Execution Audit
Token for this task, enabling correlation between the audit
record and the execution context.</t>
  </dd>
  <dt>aud_domain:</dt>
  <dd>
    <t><bcp14>REQUIRED</bcp14>.  The fully qualified domain name of the audit domain
that produced this record.</t>
  </dd>
  <dt>reg_profile:</dt>
  <dd>
    <t><bcp14>REQUIRED</bcp14>.  The regulatory profile identifier governing this
audit record.  See <xref target="regulatory-profiles"/>.</t>
  </dd>
  <dt>xref:</dt>
  <dd>
    <t><bcp14>OPTIONAL</bcp14>.  Cross-reference object for audit trail stitching.
Present when this record follows a domain boundary crossing.
See <xref target="audit-stitching"/>.</t>
  </dd>
</dl>

</section>
<section anchor="domain-specific-extensions"><name>Domain-Specific Extensions</name>

<t>Each regulatory profile <bcp14>MAY</bcp14> define additional required claims.
Domain-specific extensions are carried in a "domain_ext" object:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "domain_ext": {
    "gdpr": {
      "data_subject_category": "customer",
      "processing_purpose": "enrichment",
      "legal_basis": "legitimate_interest",
      "retention_days": 730,
      "dpo_contact": "dpo@domain-a.example.com"
    }
  }
}
]]></sourcecode></figure>

</section>
<section anchor="cross-reference-identifiers"><name>Cross-Reference Identifiers</name>

<t>Cross-reference identifiers enable trail stitching without
requiring access to the full audit records of other domains:</t>

<dl>
  <dt>boundary_id:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt>prev_jti:</dt>
  <dd>
    <t>The JTI of the last audit record in the preceding domain.
This enables sequential chain verification.</t>
  </dd>
  <dt>prev_domain:</dt>
  <dd>
    <t>The audit domain identifier of the preceding domain.</t>
  </dd>
</dl>

</section>
</section>
<section anchor="regulatory-profiles"><name>Regulatory Profile Mapping</name>

<section anchor="profile-definitions"><name>Profile Definitions</name>

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

<texttable title="Regulatory Profile Definitions" anchor="tab-profiles">
      <ttcol align='left'>Profile ID</ttcol>
      <ttcol align='left'>Framework</ttcol>
      <ttcol align='left'>Required Claims</ttcol>
      <ttcol align='left'>Retention</ttcol>
      <c>gdpr-v1</c>
      <c>EU GDPR</c>
      <c>data_subject_category, processing_purpose, legal_basis, retention_days</c>
      <c>Per purpose</c>
      <c>sox-v1</c>
      <c>US SOX</c>
      <c>control_objective, control_id, evidence_class, attestor</c>
      <c>7 years</c>
      <c>hipaa-v1</c>
      <c>US HIPAA</c>
      <c>phi_category, access_purpose, minimum_necessary, covered_entity</c>
      <c>6 years</c>
</texttable>

</section>
<section anchor="compliance-field-mapping"><name>Compliance Field Mapping</name>

<t>Each profile maps to a set of required and optional claims in the
"domain_ext" object.  An audit record <bcp14>MUST</bcp14> include all required
claims for its declared regulatory profile.  A verifier <bcp14>MUST</bcp14>
reject records missing required claims.</t>

<dl>
  <dt>GDPR Profile (gdpr-v1):</dt>
  <dd>
    <t><bcp14>REQUIRED</bcp14> claims: data_subject_category, processing_purpose,
legal_basis, retention_days.
<bcp14>OPTIONAL</bcp14> claims: dpo_contact, cross_border_transfer,
data_categories, recipients.</t>
  </dd>
  <dt>SOX Profile (sox-v1):</dt>
  <dd>
    <t><bcp14>REQUIRED</bcp14> claims: control_objective, control_id, evidence_class,
attestor.
<bcp14>OPTIONAL</bcp14> claims: deficiency_flag, management_response,
test_procedure.</t>
  </dd>
  <dt>HIPAA Profile (hipaa-v1):</dt>
  <dd>
    <t><bcp14>REQUIRED</bcp14> claims: phi_category, access_purpose,
minimum_necessary, covered_entity.
<bcp14>OPTIONAL</bcp14> claims: business_associate, disclosure_authorization,
breach_risk_assessment.</t>
  </dd>
</dl>

</section>
<section anchor="regulatory-metadata-claims"><name>Regulatory Metadata Claims</name>

<t>Regulatory metadata is carried as claims in the EAT payload
under the "reg_meta" key:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "reg_meta": {
    "profile": "gdpr-v1",
    "jurisdiction": "EU",
    "supervisory_authority": "de-bfdi",
    "cross_border": true,
    "adequacy_decision": "eu-us-dpf",
    "retention_expiry": 1763078400
  }
}
]]></sourcecode></figure>

</section>
</section>
<section anchor="audit-stitching"><name>Audit Trail Stitching</name>

<section anchor="cross-domain-correlation-protocol"><name>Cross-Domain Correlation Protocol</name>

<t>When a workflow crosses a domain boundary, the following protocol
ensures audit trail continuity:</t>

<t><list style="numbers" type="1">
  <t>The source domain creates a boundary crossing record containing
the last audit record's JTI and a newly generated boundary_id.</t>
  <t>The source domain signs the boundary crossing record and
transmits it to the destination domain along with the agent
handoff.</t>
  <t>The destination domain creates its first audit record with
an xref object referencing the boundary_id and the source
domain's last JTI.</t>
  <t>Both domains independently log the boundary crossing record
in their respective audit ledgers.</t>
</list></t>

</section>
<section anchor="boundary-crossing-records"><name>Boundary Crossing Records</name>

<t>A boundary crossing record is a JWS-signed JSON object:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "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"]
}
]]></sourcecode></figure>

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

</section>
<section anchor="partial-trail-assembly"><name>Partial Trail Assembly</name>

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

<t>This allows privacy-preserving end-to-end audit where each domain
proves its segment of the trail without exposing regulated data
to unauthorized parties.</t>

</section>
</section>
<section anchor="selective-disclosure"><name>Selective Disclosure</name>

<section anchor="using-sd-jwt-concepts-for-audit-records"><name>Using SD-JWT Concepts for Audit Records</name>

<t>Cross-domain audit records <bcp14>MAY</bcp14> use Selective Disclosure JWT
(SD-JWT) <xref target="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.</t>

<t>An SD-JWT audit record replaces direct claims with hashed
disclosures:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "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"
}
]]></sourcecode></figure>

<t>Individual claims are disclosed by providing the corresponding
disclosure values alongside the SD-JWT.</t>

</section>
<section anchor="per-domain-visibility-controls"><name>Per-Domain Visibility Controls</name>

<t>Each audit domain declares a visibility policy specifying which
claims are:</t>

<t><list style="symbols">
  <t>Public: Disclosed to all domains in the workflow trail.</t>
  <t>Boundary: Disclosed only to the immediate upstream and
downstream domains.</t>
  <t>Private: Never disclosed outside the originating domain.</t>
</list></t>

<t>The visibility policy is declared in the regulatory profile
and enforced at each domain boundary crossing.</t>

</section>
<section anchor="redaction-and-minimization-rules"><name>Redaction and Minimization Rules</name>

<t>When an audit record crosses a domain boundary, the following
rules apply:</t>

<t><list style="numbers" type="1">
  <t>Claims classified as "private" <bcp14>MUST</bcp14> be redacted using SD-JWT
disclosures.  The destination domain receives proof that the
claims exist but cannot read their values.</t>
  <t>Claims classified as "boundary" <bcp14>MUST</bcp14> be disclosed to the
immediate destination domain but redacted for subsequent
domains in the chain.</t>
  <t>Claims classified as "public" <bcp14>MUST</bcp14> be disclosed to all
domains.</t>
  <t>The minimum set of public claims required for trail stitching
is: jti, boundary_id, aud_domain, and crossing_time.</t>
</list></t>

</section>
</section>
</section>
<section anchor="resource-accounting"><name>Resource Accounting</name>

<section anchor="resource-metering"><name>Resource Metering Model</name>

<section anchor="resource-types"><name>Resource Types</name>

<t>This document defines the following resource types for agent
metering:</t>

<texttable title="Resource Type Definitions" anchor="tab-resources">
      <ttcol align='left'>Resource Type</ttcol>
      <ttcol align='left'>Unit</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c>compute</c>
      <c>cpu-ms</c>
      <c>CPU time in milliseconds</c>
      <c>memory</c>
      <c>byte-s</c>
      <c>Memory usage in byte-seconds</c>
      <c>network_egress</c>
      <c>bytes</c>
      <c>Outbound network transfer</c>
      <c>network_ingress</c>
      <c>bytes</c>
      <c>Inbound network transfer</c>
      <c>storage</c>
      <c>byte-s</c>
      <c>Persistent storage in byte-seconds</c>
      <c>api_calls</c>
      <c>count</c>
      <c>External API invocations</c>
      <c>llm_tokens</c>
      <c>count</c>
      <c>Large language model tokens consumed</c>
      <c>gpu_compute</c>
      <c>gpu-ms</c>
      <c>GPU time in milliseconds</c>
</texttable>

</section>
<section anchor="metering-points"><name>Metering Points</name>

<t>Resource meters are placed at defined points in the agent
execution pipeline:</t>

<t><list style="numbers" type="1">
  <t>Task Ingress: Resources consumed receiving and parsing task
inputs.</t>
  <t>Execution: Resources consumed during task execution proper.</t>
  <t>Tool Invocation: Resources consumed by each tool call within
a task.</t>
  <t>Task Egress: Resources consumed producing and transmitting
task outputs.</t>
  <t>Audit Overhead: Resources consumed generating and transmitting
audit records themselves.</t>
</list></t>

<t>Each metering point produces a meter reading that is included
in the task's consumption record.</t>

</section>
<section anchor="meter-reading-format"><name>Meter Reading Format</name>

<t>A meter reading is a JSON object:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "meter_point": "execution",
  "resource_type": "llm_tokens",
  "quantity": 4096,
  "unit": "count",
  "start_time": 1700000000,
  "end_time": 1700000005,
  "confidence": "measured"
}
]]></sourcecode></figure>

<t>The "confidence" field indicates whether the reading is
"measured" (exact instrumentation), "estimated" (statistical
sampling), or "allocated" (apportioned from a shared pool).</t>

</section>
</section>
<section anchor="consumption-records"><name>Consumption Records</name>

<section anchor="per-agent-resource-consumption-claims"><name>Per-Agent Resource Consumption Claims</name>

<t>Resource consumption is recorded as claims in the EAT payload
under the "resource" key:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "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"
      }
    ]
  }
}
]]></sourcecode></figure>

</section>
<section anchor="aggregation-across-dag-nodes"><name>Aggregation Across DAG Nodes</name>

<t>When a workflow DAG spans multiple tasks, consumption records
can be aggregated to produce a workflow-level resource summary.
The aggregation <bcp14>MUST</bcp14>:</t>

<t><list style="symbols">
  <t>Sum quantities of the same resource type and unit across all
DAG nodes within a domain.</t>
  <t>Maintain per-task granularity for dispute resolution.</t>
  <t>Record the aggregation method ("sum", "max", "weighted") for
each resource type.</t>
</list></t>

</section>
<section anchor="multi-tenant-isolation"><name>Multi-Tenant Isolation</name>

<t>In shared infrastructure deployments, resource meters <bcp14>MUST</bcp14>
provide tenant isolation guarantees:</t>

<t><list style="symbols">
  <t>Each agent's resource consumption <bcp14>MUST</bcp14> be independently
metered.</t>
  <t>Shared resources (e.g., shared GPU pools) <bcp14>MUST</bcp14> use the
"allocated" confidence level and document the allocation
method.</t>
  <t>Consumption records <bcp14>MUST NOT</bcp14> leak information about other
tenants' resource usage.</t>
</list></t>

</section>
</section>
<section anchor="billing-integration"><name>Billing Integration</name>

<section anchor="settlement-protocol-overview"><name>Settlement Protocol Overview</name>

<t>Settlement between domains follows a three-phase protocol:</t>

<dl>
  <dt>Phase 1 -- Reporting:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt>Phase 2 -- Reconciliation:</dt>
  <dd>
    <t>Participating domains exchange usage reports and verify that
boundary crossing records match.  Discrepancies are flagged
for manual review.</t>
  </dd>
  <dt>Phase 3 -- Settlement:</dt>
  <dd>
    <t>Reconciled usage is converted to monetary amounts using
pre-agreed rate cards.  Settlement records are logged in
each domain's audit ledger.</t>
  </dd>
</dl>

</section>
<section anchor="usage-report-format"><name>Usage Report Format</name>

<t>A usage report is a JWS-signed JSON object:</t>

<figure><sourcecode type="json"><![CDATA[
{
  "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"
}
]]></sourcecode></figure>

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

</section>
<section anchor="fair-use-enforcement-mechanisms"><name>Fair-Use Enforcement Mechanisms</name>

<t>Domains <bcp14>MAY</bcp14> enforce fair-use policies on agent resource
consumption:</t>

<t><list style="symbols">
  <t>Rate Limiting: Domains <bcp14>MAY</bcp14> impose per-agent or per-workflow
rate limits on resource types.  Rate limit policies <bcp14>SHOULD</bcp14>
be communicated in the boundary crossing record.</t>
  <t>Budget Caps: Workflows <bcp14>MAY</bcp14> carry a resource budget in the ECT
that specifies maximum consumption per resource type.  Agents
<bcp14>MUST NOT</bcp14> exceed the declared budget without obtaining a revised
ECT.</t>
  <t>Anomaly Detection: Domains <bcp14>SHOULD</bcp14> monitor consumption patterns
and flag anomalous usage (e.g., token consumption 10x above
the workflow's declared budget).</t>
</list></t>

</section>
</section>
</section>
<section anchor="integration-with-ect-and-exec-audit"><name>Integration with ECT and Exec-Audit</name>

<t>The cross-domain audit and resource accounting claims defined in
this document extend the existing token formats as follows:</t>

<dl>
  <dt>ECT Extensions (<xref target="I-D.nennemann-wimse-ect"/>):</dt>
  <dd>
    <t>The ECT payload is extended with a "resource_budget" claim
specifying per-resource-type consumption limits for the
workflow.  The ECT <bcp14>MAY</bcp14> also carry a "reg_profiles" array
listing the regulatory profiles that the workflow is expected
to traverse.</t>
  </dd>
  <dt>EAT Extensions (<xref target="I-D.nennemann-exec-audit"/>):</dt>
  <dd>
    <t>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 <bcp14>OPTIONAL</bcp14> for single-domain
deployments and <bcp14>REQUIRED</bcp14> for cross-domain workflows.</t>
  </dd>
  <dt>Backward Compatibility:</dt>
  <dd>
    <t>Existing ECT and EAT processors that do not recognize the new
claims <bcp14>MUST</bcp14> ignore them per standard JWT processing rules
<xref target="RFC7519"/>.  Cross-domain audit functionality degrades
gracefully: single-domain deployments continue to function
without modification.</t>
  </dd>
</dl>

</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<section anchor="audit-trail-tampering-across-domains"><name>Audit Trail Tampering Across Domains</name>

<t>Because each domain signs its own audit records independently,
a compromised domain can fabricate or alter its segment of the
audit trail.  Mitigations include:</t>

<t><list style="symbols">
  <t>Requiring Level 3 assurance (ledger-anchored EATs) for
cross-domain workflows in regulated environments.</t>
  <t>Cross-domain ledger anchoring as defined in
<xref target="I-D.nennemann-exec-audit"/> to detect tampering after the
fact.</t>
  <t>Independent third-party audit of boundary crossing records.</t>
</list></t>

</section>
<section anchor="resource-metering-fraud"><name>Resource Metering Fraud</name>

<t>A malicious domain could under-report resource consumption to
reduce settlement obligations or over-report to inflate charges.
Mitigations include:</t>

<t><list style="symbols">
  <t>Bilateral verification of boundary crossing records, which
constrain the plausible range of resource consumption.</t>
  <t>Statistical sampling and spot-checking of consumption records
against actual infrastructure metrics.</t>
  <t>Requiring "measured" confidence level for high-value resource
types and rejecting "estimated" readings above a threshold.</t>
</list></t>

</section>
<section anchor="privacy-leakage-through-audit-correlation"><name>Privacy Leakage Through Audit Correlation</name>

<t>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:</t>

<t><list style="symbols">
  <t>Batching boundary crossing records to obscure individual
workflow timing.</t>
  <t>Using domain-specific pseudonymous identifiers in cross-
references rather than globally unique agent identifiers.</t>
  <t>Minimizing the set of public claims to the structural minimum
required for trail stitching.</t>
</list></t>

</section>
<section anchor="selective-disclosure-attacks"><name>Selective Disclosure Attacks</name>

<t>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 <bcp14>MUST</bcp14> use
cryptographically random salts of at least 128 bits for each
SD-JWT disclosure.</t>

</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<section anchor="jwt-claims-registration"><name>JWT Claims Registration</name>

<t>This document requests registration of the following claims in
the JSON Web Token Claims registry established by <xref target="RFC7519"/>:</t>

<texttable title="JWT Claims Registration" anchor="tab-claims">
      <ttcol align='left'>Claim Name</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>aud_domain</c>
      <c>Audit domain identifier</c>
      <c>This document</c>
      <c>reg_profile</c>
      <c>Regulatory profile identifier</c>
      <c>This document</c>
      <c>reg_meta</c>
      <c>Regulatory metadata object</c>
      <c>This document</c>
      <c>xref</c>
      <c>Cross-domain reference object</c>
      <c>This document</c>
      <c>domain_ext</c>
      <c>Domain-specific extension claims</c>
      <c>This document</c>
      <c>resource</c>
      <c>Resource consumption record</c>
      <c>This document</c>
      <c>resource_budget</c>
      <c>Resource budget limits</c>
      <c>This document</c>
</texttable>

</section>
<section anchor="regulatory-profile-registry"><name>Regulatory Profile Registry</name>

<t>This document establishes a new "Agent Audit Regulatory Profiles"
registry.  The registration policy is Specification Required
<xref target="RFC8126"/>.</t>

<t>Initial registrations:</t>

<texttable title="Regulatory Profile Registry" anchor="tab-reg-profiles">
      <ttcol align='left'>Profile ID</ttcol>
      <ttcol align='left'>Framework</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>gdpr-v1</c>
      <c>EU General Data Protection Regulation</c>
      <c>This document</c>
      <c>sox-v1</c>
      <c>US Sarbanes-Oxley Act</c>
      <c>This document</c>
      <c>hipaa-v1</c>
      <c>US Health Insurance Portability and Accountability Act</c>
      <c>This document</c>
</texttable>

</section>
<section anchor="resource-type-registry"><name>Resource Type Registry</name>

<t>This document establishes a new "Agent Resource Types" registry.
The registration policy is Specification Required <xref target="RFC8126"/>.</t>

<t>Initial registrations are listed in <xref target="tab-resources"/>.</t>

</section>
</section>


  </middle>

  <back>


<references title='References' anchor="sec-combined-references">

    <references title='Normative References' anchor="sec-normative-references">



<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC7519">
  <front>
    <title>JSON Web Token (JWT)</title>
    <author fullname="M. Jones" initials="M." surname="Jones"/>
    <author fullname="J. Bradley" initials="J." surname="Bradley"/>
    <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
    <date month="May" year="2015"/>
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7519"/>
  <seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>
<reference anchor="RFC7515">
  <front>
    <title>JSON Web Signature (JWS)</title>
    <author fullname="M. Jones" initials="M." surname="Jones"/>
    <author fullname="J. Bradley" initials="J." surname="Bradley"/>
    <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
    <date month="May" year="2015"/>
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7515"/>
  <seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>
<reference anchor="RFC9110">
  <front>
    <title>HTTP Semantics</title>
    <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
    <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
    <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
    <date month="June" year="2022"/>
    <abstract>
      <t>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.</t>
      <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="97"/>
  <seriesInfo name="RFC" value="9110"/>
  <seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>

<reference anchor="I-D.nennemann-wimse-ect" target="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/">
  <front>
    <title>Execution Context Tokens for Distributed Agentic Workflows</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="I-D.nennemann-exec-audit" target="https://datatracker.ietf.org/doc/draft-nennemann-exec-audit/">
  <front>
    <title>Cross-Domain Execution Audit Tokens</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


<reference anchor="RFC8126">
  <front>
    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
    <author fullname="M. Cotton" initials="M." surname="Cotton"/>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <author fullname="T. Narten" initials="T." surname="Narten"/>
    <date month="June" year="2017"/>
    <abstract>
      <t>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).</t>
      <t>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.</t>
      <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="26"/>
  <seriesInfo name="RFC" value="8126"/>
  <seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>



    </references>

    <references title='Informative References' anchor="sec-informative-references">

<reference anchor="I-D.nennemann-agent-gap-analysis" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/">
  <front>
    <title>Gap Analysis for Autonomous Agent Protocols</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>



<reference anchor="I-D.ietf-scitt-architecture">
   <front>
      <title>An Architecture for Trustworthy and Transparent Digital Supply Chains</title>
      <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
         <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname="Antoine Delignat-Lavaud" initials="A." surname="Delignat-Lavaud">
         <organization>Microsoft Research</organization>
      </author>
      <author fullname="Cedric Fournet" initials="C." surname="Fournet">
         <organization>Microsoft Research</organization>
      </author>
      <author fullname="Yogesh Deshpande" initials="Y." surname="Deshpande">
         <organization>ARM</organization>
      </author>
      <author fullname="Steve Lasker" initials="S." surname="Lasker">
         </author>
      <date day="10" month="October" year="2025"/>
      <abstract>
	 <t>   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.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-scitt-architecture-22"/>
   
</reference>
<reference anchor="RFC9334">
  <front>
    <title>Remote ATtestation procedureS (RATS) Architecture</title>
    <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
    <author fullname="D. Thaler" initials="D." surname="Thaler"/>
    <author fullname="M. Richardson" initials="M." surname="Richardson"/>
    <author fullname="N. Smith" initials="N." surname="Smith"/>
    <author fullname="W. Pan" initials="W." surname="Pan"/>
    <date month="January" year="2023"/>
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9334"/>
  <seriesInfo name="DOI" value="10.17487/RFC9334"/>
</reference>

<reference anchor="SD-JWT" target="https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/">
  <front>
    <title>Selective Disclosure for JWTs (SD-JWT)</title>
    <author >
      <organization></organization>
    </author>
    <date year="2024"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-oauth-selective-disclosure-jwt"/>
</reference>
<reference anchor="EU-AI-ACT" target="https://eur-lex.europa.eu/eli/reg/2024/1689/oj">
  <front>
    <title>Regulation (EU) 2024/1689 (AI Act)</title>
    <author >
      <organization>European Parliament and Council</organization>
    </author>
    <date year="2024"/>
  </front>
</reference>


    </references>

</references>


<?line 818?>

<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>

<t>The author thanks the participants of the NMOP working group
for their feedback on agent management and operational
challenges.</t>

</section>


  </back>

<!-- ##markdown-source:
[encoded data, 12322 characters]
+N6WXWyrSUO1cbA9shT5SpalqgiK/ze7cTrVEGsAAA==

-->

</rfc>

