| Internet-Draft | Verifiable Usage Accounting for IoA | May 2026 |
| Zhang, et al. | Expires 8 November 2026 | [Page] |
This document describes a usage accounting and evidence framework for the Internet of Agents (IoA). In cross-domain agent collaboration, agents may attach to gateways, discover capabilities, delegate subtasks, invoke tools, consume model or compute resources, and produce auditable outcomes. Existing application logs or platform-specific billing interfaces are insufficient for interoperable accounting across agents, gateways, and administrative domains.¶
This document defines requirements and a common object model for verifiable usage accounting, including Accounting Contexts, Metering Profiles, Measurement Dimensions, Usage Event Records, and Accounting Evidence References. These objects are intended to support interoperable recording, correlation, export, verification, correction, and dispute handling for agent collaboration events.¶
This document does not define pricing, charging policy, token issuance, financial settlement, revenue-sharing rules, invoices, or business support system interfaces. It focuses on protocol-visible accounting records and evidence objects that may be used by other systems.¶
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 8 November 2026.¶
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.¶
The Internet of Agents (IoA) envisions large-scale collaboration among autonomous or semi-autonomous agents across domains, vendors, networks, and execution environments. Agents may act on behalf of users, services, organizations, or other agents. They may also interact through Agent Gateways, agent-to-agent session protocols, capability directories, task protocols, tool invocation interfaces, and model services.¶
Once agents collaborate across administrative domains, a system needs a common way to record what occurred during the collaboration. A task may be decomposed into subtasks, delegated to several agents, routed through gateways, and completed by invoking models, tools, data services, or network functions. The resulting usage information is useful for resource accounting, cost allocation, audit, operational analysis, quota control, accountability, and dispute handling.¶
Existing application logs, local billing records, or platform-specific usage APIs do not provide a common cross-domain accounting view. They often lack stable task correlation, gateway provenance, signed evidence references, usage-category semantics, measurement-dimension declarations, privacy-controlled export, and correction semantics. In addition, coarse-grained records such as "API request count" or "total input/output tokens" do not distinguish between orchestration, execution, tool invocation, delegated subtasks, reasoning or inference cost, gateway mediation, and result verification.¶
This document defines a protocol-visible object model for verifiable usage accounting in IoA. It is inspired by existing Internet accounting and measurement work, including accounting management concepts [RFC2975], network access accounting [RFC2866], and flow information export [RFC7011]. However, the objects defined here are intended for agent collaboration rather than packet flows or network access sessions.¶
The key design principle is separation between accounting facts and business charging. This document defines usage accounting contexts, metering profiles, measurement dimensions, event records, and evidence references. It does not define prices, tariffs, token economics, revenue sharing, invoices, or financial settlement.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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.¶
This document specifies:¶
This document does not specify:¶
An IoA deployment may contain Requesting Agents, Serving Agents, Agent Gateways, Accounting Exporters, Accounting Collectors, and Evidence Verifiers. The accounting model can be used with gateway-mediated interaction, direct agent-to-agent interaction, or a combination of both. A gateway is a common observation and enforcement point, but the object model does not require every event to be observed by the same gateway.¶
The core relationship among the accounting objects is shown in Figure 1. An Accounting Context defines the scope of accounting for a task, session, invocation, or collaboration. A Metering Profile defines how usage is measured and what evidence is required. Usage Event Records describe individual accounting-relevant events within that context. Accounting Evidence References bind records to signatures, hashes, receipts, authorization references, trace evidence, result attestations, or human confirmations.¶
+------------------------------------------------------+
| Accounting Context |
| - task/session/invocation identifiers |
| - accounting domain and observation scope |
| - policy, privacy, and evidence requirements |
+---------------------------+--------------------------+
|
| references
v
+------------------------------------------------------+
| Metering Profile |
| - usage categories and measurement dimensions |
| - aggregation, privacy, and export behavior |
| - required evidence and correction behavior |
+---------------------------+--------------------------+
|
| applies to
v
+------------------------------------------------------+
| Usage Event Records |
| - task, delegation, model, tool, gateway events |
| - usage measurements, result status, sequence |
+---------------------------+--------------------------+
|
| supported by
v
+------------------------------------------------------+
| Accounting Evidence References |
| - signatures, hashes, receipts |
| - authorization, trace, result, confirmation |
+------------------------------------------------------+
Figure 2 illustrates how these objects are used during a cross-domain collaboration. The accounting context is normally established before or during task/session setup. Usage event records are generated as the collaboration proceeds. Evidence references are attached when records require later verification. Exporters can then send records or summaries to collectors according to the Metering Profile and privacy policy.¶
Requesting Agent Gateway A Gateway B Serving Agent
| Exporter Collector |
| | | |
| 1. setup / invocation handoff |
|----------------->|--------------->|------------->|
| | | |
| 2. establish Accounting Context and profile |
|<---------------->|<-------------->|<------------>|
| | | |
| 3. task execution, delegation, model/tool use |
|----------------->|--------------->|------------->|
| | | |
| 4. generate Usage Event Records |
| |<---observe---->| |
| | | |
| 5. bind Evidence References |
| |---sign/hash--->| |
| | | |
| 6. export records or summaries |
| |--------------->| |
| | | |
| 7. correction or dispute evidence, if needed |
| |<-------------->| |
The accounting model is not required to expose agent internals or raw prompt content. A gateway or platform may generate summary records, privacy-preserving digests, or evidence references according to local policy. For example, an exported record can indicate that a result was verified and signed by a gateway without disclosing the raw ticket, prompt, tool output, or business data used to make that determination.¶
An Accounting Context defines the scope within which Usage Event Records are correlated and interpreted. An Accounting Context MAY be established during agent attachment, capability registration, discovery handoff, task creation, session establishment, or invocation setup.¶
An Accounting Context SHOULD contain the following fields:¶
An Accounting Context MUST be unambiguous within the accounting domain that asserts it. If a context is propagated across domains, each receiving entity MUST be able to determine the asserting entity, the validity of the context, and the applicable disclosure constraints.¶
A Metering Profile describes the accounting behavior supported or required by an agent, capability, gateway, service, or accounting domain.¶
A Metering Profile MAY be referenced by a gateway capability directory entry, capability advertisement, task object, handoff reference, session setup message, or policy object. If multiple profiles apply, the effective profile MUST be determined according to local policy and MUST be auditable.¶
A Metering Profile SHOULD specify:¶
A Metering Profile MAY declare one or more measurement dimensions. A measurement dimension identifies what is measured, the unit used for the measurement, the applicable modality or usage category, and how the value is obtained and aggregated. Measurement dimensions provide a common way to describe text-token usage, model inference usage, multimodal processing usage, gateway usage, quota state, workflow usage, and verified-result usage.¶
A measurement dimension SHOULD contain:¶
Examples of measurement dimensions include input-token-count, output-token-count, total-token-count, cached-token-count, reasoning-token-count, processing-time-ms, request-count, transferred-bytes, quota-used, quota-limit, image-count, image-pixel-count, image-quality-level, video-duration-seconds, frame-rate, audio-duration-seconds, sample-rate, channel-count, tool-call-count, workflow-step-count, delegation-count, verified-result-count, and standard-compute-usage.¶
The usage-category of each Measurement Dimension SHOULD be one of the supported usage categories declared by the Metering Profile, unless the dimension is explicitly marked as extension-specific.¶
Reasoning or chain-of-thought resource consumption can be represented as a measurement dimension, such as reasoning-token-count or reasoning-compute-duration. This document only accounts for the resource usage of such reasoning processes; it does not require or encourage disclosure of chain-of-thought content.¶
Measurement dimensions are accounting metadata. They do not define a pricing model, charging rule, tariff, or business valuation method.¶
A Metering Profile SHOULD specify content recording behavior. Supported behavior can include disabled, digest-only, metadata-only, excerpt-only, or full-content recording under explicit policy. Full-content recording MUST NOT be the default behavior for cross-domain export.¶
A Metering Profile SHOULD also specify export behavior, including whether records are retained locally, exported as per-event records, exported as summaries, exported in batches, streamed to a collector, or exported only through evidence references. Export behavior MUST be evaluated together with the privacy behavior and evidence requirements of the profile.¶
A Usage Event Record describes an observed accounting-relevant event. It is not required to contain all raw operational data. It SHOULD contain enough information to support correlation, aggregation, verification, correction, and dispute handling.¶
A Usage Event Record SHOULD contain the following fields:¶
A Usage Event Record that is exported across administrative domains MUST include enough provenance information for the receiver to identify the asserting gateway, platform, or accounting domain. The receiver MUST NOT treat a record as verified solely because it is syntactically valid.¶
An Accounting Evidence Reference links a Usage Event Record to evidence that supports the record. This document does not require a particular evidence format. Implementations may use existing mechanisms such as JOSE [RFC7515], COSE [RFC9052], JWT [RFC7519], CWT [RFC8392], or selective disclosure mechanisms where appropriate.¶
An Accounting Evidence Reference SHOULD contain:¶
Evidence references MUST NOT require disclosure of raw prompts, tool results, personal data, or sensitive operational data unless such disclosure is allowed by policy and necessary for the accounting purpose.¶
The following initial usage event categories are defined for interoperability. Future specifications may extend this list.¶
These categories describe accounting semantics and do not imply any particular pricing or charging rule.¶
An Accounting Context MAY be established when an agent attaches to a gateway, a gateway accepts or creates a capability directory entry, a task is created or accepted, an invocation handoff is returned, a session or collaboration group is established, or a policy decision requires accounting or audit.¶
The entity establishing the context MUST determine the applicable Metering Profile and evidence policy before usage events are exported across administrative domains. If no compatible profile exists, the gateway or platform MAY reject the interaction, fall back to local-only accounting, or export only a minimal summary according to policy.¶
Accounting Context establishment SHOULD be bound to authentication and authorization decisions where available. An accounting context MUST NOT be used as proof of authorization unless it explicitly references verifiable authorization evidence.¶
A gateway or platform component SHOULD generate a Usage Event Record when an accounting-relevant event is observed. The granularity of event generation depends on the Metering Profile.¶
Implementations SHOULD support at least task-start and task-complete or task-failed records, delegation records, tool-invocation records, model-inference or compute-usage records, and correction records.¶
A Usage Event Record MUST include ordering or deduplication information if it can be retransmitted, corrected, or exported through multiple gateways or platforms.¶
A Usage Event Record SHOULD be bound to evidence according to the applicable evidence policy. Evidence binding MAY be achieved by embedding evidence, including a digest, including a URI, or referencing a protected evidence store.¶
Evidence binding SHOULD support integrity verification of the record, provenance verification of the asserting gateway or domain, correlation with authorization, consent, policy, or task context, result verification when a record asserts a verified outcome, and later dispute handling without exposing more data than necessary.¶
If evidence is unavailable due to privacy, retention, or policy constraints, the record MUST indicate that evidence is unavailable and SHOULD include the reason class.¶
Gateways or platforms MAY export Usage Event Records or summaries to other gateways, platforms, or collectors. Export behavior MUST follow the Metering Profile and privacy-scope constraints associated with the Accounting Context.¶
Cross-domain export SHOULD support record authentication and integrity protection, replay protection, duplicate detection, batch and streaming export models, summary export when raw event export is not allowed, correction records, and receiver-side validation of provenance and freshness.¶
A receiving entity MUST apply local policy before accepting exported accounting data for operational decisions. A receiving entity SHOULD retain the source identifier, received time, verification status, and any transformation performed on the record.¶
Accounting records may require correction because of delayed events, clock skew, aggregation errors, task cancellation, gateway failures, or later result verification.¶
A correction record MUST reference the original record or record set that it corrects. It MUST indicate whether it replaces, amends, reverses, or annotates the original record.¶
A dispute record SHOULD reference the disputed records, the accounting context, the asserting entity, the dispute reason, evidence references submitted by the disputing entity, and the dispute status.¶
This document defines only protocol-visible dispute references and evidence objects. It does not define arbitration rules, legal process, liability, compensation, or financial settlement.¶
The following examples are illustrative and are not a normative serialization profile.¶
{
"accounting_context_id": "acctx-20260507-001",
"accounting_domain_id": "example.net",
"gateway_id": "agw-east-1",
"task_id": "task-5gc-fault-1192",
"session_id": "sess-71d1",
"trace_id": "trace-88b7",
"policy_ref": "policy://example.net/ioa/accounting/basic",
"metering_profile_ref": "profile://example.net/scu-v1",
"evidence_policy": {
"signature_required": true,
"result_evidence_required": true,
"raw_prompt_export": false
},
"validity": {
"not_before": "2026-05-07T06:00:00Z",
"not_after": "2026-05-07T12:00:00Z"
}
}
{
"profile_id": "profile://example.net/scu-v1",
"version": "1.0",
"supported_usage_categories": [
"tool-invocation",
"model-inference",
"multimodal-processing"
],
"measurement_dimensions": [
{
"dimension_id": "input-token-count",
"usage_category": "model-inference",
"modality": "text",
"unit": "token",
"value_type": "integer",
"measurement_method": "provider-reported",
"aggregation_scope": "per-inference",
"privacy_class": "usage-only"
},
{
"dimension_id": "output-token-count",
"usage_category": "model-inference",
"modality": "text",
"unit": "token",
"value_type": "integer",
"measurement_method": "provider-reported",
"aggregation_scope": "per-inference",
"privacy_class": "usage-only"
},
{
"dimension_id": "standard-compute-usage",
"usage_category": "tool-invocation",
"unit": "standard-compute-unit",
"value_type": "decimal",
"measurement_method": "observed",
"aggregation_scope": "per-tool-call",
"privacy_class": "usage-only"
},
{
"dimension_id": "reasoning-token-count",
"usage_category": "model-inference",
"modality": "text",
"unit": "token",
"value_type": "integer",
"measurement_method": "provider-reported",
"aggregation_scope": "per-inference",
"privacy_class": "usage-only"
},
{
"dimension_id": "total-token-count",
"usage_category": "model-inference",
"modality": "text",
"unit": "token",
"value_type": "integer",
"measurement_method": "derived",
"aggregation_scope": "per-inference",
"privacy_class": "usage-only"
},
{
"dimension_id": "processing-time-ms",
"usage_category": "tool-invocation",
"unit": "millisecond",
"value_type": "integer",
"measurement_method": "observed",
"aggregation_scope": "per-tool-call",
"privacy_class": "usage-only"
}
]
}
{
"record_id": "uer-20260507-0038",
"accounting_context_id": "acctx-20260507-001",
"event_type": "model-inference",
"event_time": "2026-05-07T06:12:45Z",
"observation_point": "agw-east-1",
"actor_ref": "agent:core-network-diagnosis",
"target_ref": "model:diagnosis-llm-v1",
"usage_category": "model-inference",
"usage_measurements": {
"input-token-count": 1832,
"output-token-count": 412,
"reasoning-token-count": 960,
"total-token-count": 3204
},
"result_status": "completed",
"sequence_info": {
"sequence": 38,
"previous_record_hash": "sha256-..."
},
"evidence_ref": [
{
"evidence_id": "ev-0038",
"evidence_type": "receipt",
"digest_algorithm": "sha-256",
"digest": "..."
}
]
}
{
"record_id": "uer-20260507-0037",
"accounting_context_id": "acctx-20260507-001",
"event_type": "tool-call",
"event_time": "2026-05-07T06:12:43Z",
"observation_point": "agw-east-1",
"actor_ref": "agent:core-network-diagnosis",
"target_ref": "tool:amf-log-analysis",
"usage_category": "tool-invocation",
"usage_measurements": {
"standard-compute-usage": 1200,
"processing-time-ms": 1840
},
"result_status": "completed",
"sequence_info": {
"sequence": 37,
"previous_record_hash": "sha256-..."
},
"evidence_ref": [
{
"evidence_id": "ev-0037",
"evidence_type": "trace-hash",
"digest_algorithm": "sha-256",
"digest": "..."
}
]
}
Usage accounting records can reveal sensitive information about users, organizations, agents, tasks, capabilities, tools, business workflows, network operations, and resource consumption. Implementations MUST minimize disclosure according to the accounting purpose.¶
Accounting records exported across domains SHOULD avoid raw prompts, raw tool outputs, personal data, confidential business data, and detailed operational logs unless explicitly authorized and necessary. Privacy-preserving summaries, pseudonymous identifiers, redaction, selective disclosure, and digest-only evidence references SHOULD be used where possible.¶
A Metering Profile SHOULD state whether records are event-level, aggregated, sampled, or summary-only. It SHOULD also state retention expectations and disclosure constraints.¶
The ability to correlate records across gateways or sessions can improve audit and dispute handling, but it can also enable tracking. Accounting Context identifiers and trace identifiers SHOULD be scoped, rotated, or pseudonymized according to policy.¶
Accounting records may influence quota decisions, audit findings, operational analysis, and downstream business systems. Attackers may attempt to forge, modify, replay, suppress, duplicate, delay, or selectively disclose records.¶
Implementations SHOULD provide integrity protection, source authentication, replay protection, freshness validation, and duplicate detection for exported records. Existing mechanisms such as TLS [RFC8446], JOSE [RFC7515], COSE [RFC9052], JWT [RFC7519], and CWT [RFC8392] may be used as appropriate.¶
A receiving entity MUST NOT treat a Usage Event Record as trustworthy only because it is syntactically valid. The receiving entity SHOULD validate the asserting domain, signature status, freshness, evidence references, and applicable policy.¶
Records that contain usage values may be manipulated to inflate, suppress, or shift apparent usage. Implementations SHOULD support correction records, evidence references, and audit trails for changes to accounting state.¶
Result-verification records are especially sensitive because they may assert that a task outcome occurred. Such records SHOULD be bound to evidence, policy, and verification method. If human confirmation is used, the record SHOULD indicate the confirmation reference without exposing unnecessary personal data.¶
Accounting data loss can affect auditability. Implementations SHOULD consider reliable export, local buffering, non-volatile storage, acknowledgements, or retransmission where archival accounting is required by deployment policy.¶
This document requests no IANA actions in this version.¶
Future versions may request creation of registries for IoA Usage Event Types, IoA Usage Categories, IoA Measurement Dimensions, IoA Usage Units, IoA Measurement Methods, IoA Accounting Evidence Types, and IoA Accounting Result Status Values.¶