Mission Consumption Metering

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 22 February 2027.¶

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

Table of Contents

1. Introduction

Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") bounds what an agent may do; the runtime enforcement profile ([I-D.draft-mcguinness-mission-runtime]) enforces each consequential action at the point of use. A long-running agentic task also needs bounds on how much: cumulative spend, call volume, and wall-clock activity. Those are not per-action constraints; they are counters that deplete across the life of the Mission, and enforcing them is a metering problem with reserve, commit, retry, and distributed-consistency concerns of its own.¶

This document defines that metering layer:¶

• the consumption-bounds vocabulary a Mission Intent carries,¶

• the metering semantics a runtime deployment enforces, and¶

• the AuthZEN wire binding ([I-D.draft-mcguinness-mission-authzen]) for settlement and duration-lease renewal.¶

2. Status: An Experimental Extension

This document is optional and experimental: adopt it for evaluation, not as a stable interface. Metering cumulative bounds exactly under distributed decision points is a distributed-counting problem, and the reserve, commit, lease, and settlement machinery here is expected to evolve with implementation experience.¶

A deployment that does not implement this document carries no consumption bounds on its Missions and is fully conformant to the issuance and runtime profiles. The issuance profile's max_derivations is not a consumption bound: it is enforced by the issuing Authorization Server at each derivation and needs none of this document ([I-D.draft-mcguinness-oauth-mission]).¶

The consent-integrity rule of Section 6.1 is the boundary that makes this safe to omit: a bound is rendered to an Approver only where it is actually metered.¶

3. Relationship to the Issuance and Runtime Profiles

This document depends normatively on the issuance profile and the runtime profile and is not implementable alone. It defines its consumption bounds as members of the Mission Intent controls object, using the extension seam the issuance profile provides; they are carried on the Mission and committed by intent_hash exactly as any other Intent member. Metering is performed by the runtime profile's PDP within a documented enforcement scope; this document adds metering semantics to the runtime profile's decision contract and changes no issuance protocol, though it does add consent-surface obligations on the Mission Issuer (Section 6.1).¶

4. Conventions and 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.¶

Consumption bound:

A cumulative bound on Mission activity that depletes as the Mission is used, as distinct from a per-action constraint that is evaluated independently on each action.¶

5. Mission Substrate

This profile is defined against the Mission model rather than against OAuth 2.0 mechanics: it is a substrate-neutral consumer, and this section is its consumption declaration under the rule of Mission Substrate Requirements ([I-D.draft-mcguinness-mission-substrate]) that a substrate-neutral profile declare the kernel functions and optional capabilities it consumes.¶

From the contextual-governance kernel it consumes the Mission Identifier and issuer, the kernel's Mission Reference and Controller, which key every consumption counter; and the immutable Approved Context, of which the bounds are part as Mission Intent controls members. The kernel requires no particular integrity anchors: intent_hash is the OAuth binding's commitment to that approved value, and it commits the bounds like any other Intent member (Section 3).¶

It consumes these optional capabilities:¶

The portability claim is capability-scoped rather than substrate-wide for the reason the substrate's Capability Confusion consideration states: every property this profile requires matches an explicit capability claim and its scope, never the generic statement that a binding supports Missions. Hosting under another binding also requires a representation mapping: the bounds carried inside the binding's own Approved Context and covered by its own commitment mechanism, as the OAuth binding carries them in the Mission Intent and commits them through intent_hash.¶

6. Consumption Bounds

A Mission Intent controls object ([I-D.draft-mcguinness-oauth-mission]) MAY carry these members:¶

max_budget:

OPTIONAL. An object. A hard cap on cumulative monetary spend under the Mission. It carries the same {amount, currency} shape as the max_amount Common Constraint the issuance profile seeds, so the per-action cap and this cumulative cap read alike. Has the members:¶

amount:

REQUIRED. A string. A decimal number.¶

currency:

REQUIRED. A string. An ISO 4217 currency code.¶

max_calls:

OPTIONAL. An array of objects. Hard caps on the count of consequential call events. Each object has the members:¶

call_class:

REQUIRED. A string. The named call class to meter. A call_class value SHOULD be drawn from the actions identifiers of the entry's mission_resource_access ([I-D.draft-mcguinness-oauth-mission]), so the metered class maps to evaluated actions; a deployment that meters a coarser or cross-entry class defines that class's membership, and such a class is deployment-defined and not interoperable, like a deployment-defined constraint. (Named call_class rather than scope to avoid collision with the OAuth scope parameter and claim.)¶

count:

REQUIRED. An integer. 1 or greater.¶

max_duration:

OPTIONAL. A string. An ISO 8601 duration (for example, PT8H), matching the duration rule in Appendix A of [RFC3339], bounding cumulative wall-clock consequential activity under the Mission. It is distinct from the Mission's expires_at, which bounds issuance rather than activity.¶

max_egress_volume:

OPTIONAL. An object with one or both members bytes and messages, each an integer, 1 or greater: hard caps on cumulative egress under the Mission across consequential external-communication and external-commitment actions ([I-D.draft-mcguinness-mission-runtime]), as the total size in bytes of those actions' bound payload parameters and the count of such actions. It bounds the volume of within-scope laundering; it does not detect it.¶

exclusive:

OPTIONAL. An array of exclusivity groups, each an array of two or more selectors. A selector is an object with resource (REQUIRED, a string) and actions (OPTIONAL, an array of strings); it matches a consequential action whose resource equals resource and, when actions is present, whose invoked action is within it. Within a group, the selectors name authority the Approver consents MUST NOT be combined under this Mission (Section 8).¶

The bounds are carried on the Mission and committed by intent_hash. They are not enforced by the Authorization Server at issuance; they are enforced by the runtime layer at the point of use (Section 7).¶

Example Mission Intent controls carrying three of the four bounds alongside the issuance profile's members:¶

{
  "controls": {
    "acr": "urn:example:acr:mfa",
    "max_derivations": 200,
    "max_budget": { "amount": "5000.00", "currency": "USD" },
    "max_calls": [
      { "call_class": "journal-entries.write", "count": 50 }
    ],
    "max_duration": "PT8H"
  }
}

7. Consumption Metering

Consumption bounds are enforced by the runtime profile's PDP ([I-D.draft-mcguinness-mission-runtime]), not at issuance:¶

• max_budget: the PDP performs an atomic reserve-or-charge against the remaining balance for each consequential action and MUST refuse when the remaining balance is insufficient.¶

• max_calls: the PDP increments an atomic counter for the named call_class and MUST refuse a call past count.¶

• max_egress_volume: the PDP adds the action's bound payload size and increments the action count atomically with the permit and MUST refuse an action that would exceed either cap. Payload size is measured over the parameter bytes committed by parameter_digest ([I-D.draft-mcguinness-mission-runtime]); the Operation Profile defines the measurement so PDPs accumulate consistently. For a reference-typed parameter, one that carries an attachment identifier or URL whose referent egresses while the pointer is what parameter_digest commits, the Operation Profile MUST measure the dereferenced payload size, or the deployment MUST exclude such actions from a claimed bytes bound. Counting the pointer bytes alone understates the egress.¶

• max_duration: the PDP accumulates the duration of consequential activity it reserves, commits, or permits, under these rules:¶

  1. The PDP MUST refuse once the accumulated total would exceed the bound.¶

  2. The PDP MUST accumulate max_duration as the sum of per-action measured durations, not the union of activity intervals, so concurrent actions each count against the bound.¶

  3. For an action whose duration is not known before execution, the PDP MUST either reserve a bounded maximum duration or issue a duration lease that expires unless renewed.¶

  4. The PEP MUST stop the action or obtain a new permit before the reservation or lease is exhausted.¶

  5. Lease boundaries MUST carry a clock-skew margin: the PEP renews or stops ahead of expiry by at least the deployment's skew bound, so a renewal in flight does not race the expiry it extends.¶

  6. For an action that cannot be safely stopped mid-execution, lease exhaustion is handled as an in-flight outcome under the orchestration profile's dispatched_not_committed or unknown classes ([I-D.draft-mcguinness-mission-orchestration]), not by severing the action.¶

  7. After execution, the PEP MUST report the measured duration so the PDP can commit actual use and release any unused reservation.¶

  The Operation Profile defines how a single action's duration is measured so that PDPs accumulate consistently.¶

A per-entry constraints value that expresses a cumulative consumption bound is metered the same way. When an applicable entry or the Mission's controls carries such a bound, the PDP MUST meter use against it. The PDP MUST refuse a consequential action that would exceed it. The runtime profile's fail-closed rule stands beneath all of this: an unmetered or unrecognized consumption bound MUST cause refusal rather than silent pass-through ([I-D.draft-mcguinness-mission-runtime]).¶

8. Exclusivity and Separation of Duty

The exclusive control (Section 6) is not a consumption bound: it is a stateful separation-of-duty rule enforced with the same machinery. Within an exclusivity group, the first permitted consequential action matching a selector latches the group to that selector, atomically with the permit; for the Mission's remaining lifetime the PDP MUST refuse a consequential action matching any other selector of the same group. The latch is per group and per Mission and is PDP-side operational state like a consumption counter (Section 7).¶

The latch tracks execution, not permit issuance: a permit whose action is affirmatively not executed never combined the group's authority, so when Execution Evidence reports that outcome within the strongly consistent latch domain the PDP releases the latch, restoring monotonic narrowing rather than breaking it. Absent that affirmative non-execution the latch does not unlatch: narrowing by exercise is monotonic, like every other narrowing in the family.¶

The latch is exempt from the Bounded-consistency enforcement profile of Section 7.1. A counter degrades gracefully under a per-PDP sub-budget or a reconciliation window; a separation-of-duty rule violated once is violated permanently, and two PDPs can latch the same group to opposite selectors within the window. Therefore:¶

• An exclusivity group MUST be enforced under the Exact enforcement profile of Section 7.1, in a single strongly consistent per-Mission latch domain (the runtime profile's Mission-sharding guidance makes the Mission the consistency unit, [I-D.draft-mcguinness-mission-runtime]).¶

• The Bounded-consistency enforcement profile MUST NOT be applied to exclusive.¶

• The deployment MUST name the latch domain in its Enforcement Scope Statement.¶

Exclusivity turns the quarantine deployment pattern ([I-D.draft-mcguinness-mission-architecture]) into consented, enforceable structure: an Approver can approve a Mission that may read a sensitive store or communicate externally, but never both. The groups are consented at the approval event, committed by intent_hash with the other controls members, and rendered in the consent disclosure (Section 6.1 applies unchanged).¶

In the AuthZEN binding, a refusal under a latched group is denied with exclusivity_latched, an extension of the runtime denial set under the AuthZEN profile's coordinated-extension conventions ([I-D.draft-mcguinness-mission-authzen]), and recorded as the denial_reason in Decision Evidence. A PDP that cannot establish a group's latch state fails closed for the actions the group covers, per the runtime profile's availability posture.¶

9. Aggregate Bounds

The bounds of this document are Mission-keyed. A deployment MAY additionally meter the same bound classes across Missions, keyed by the Mission's subject, by the approved client_id, or by a lineage-keyed budget identifier shared by a root Mission and every Child Mission derived from it, so a fleet operator can cap what an agent identity, a Subject, or a Mission's whole derivation lineage consumes in total rather than per task. The counter semantics, reserve/commit postures, and refusal behavior are unchanged; only the key differs.¶

A lineage-keyed budget identifier and its authoritative shared counter are the only mechanism this document defines for a lineage-wide aggregate consumption bound: they meter across every Mission a derivation lineage contains, not within one Mission alone. A Child Mission's own derivation counter is independent of its parent's and bounds nothing beyond that Child Mission itself ([I-D.draft-mcguinness-oauth-mission-child-delegation]); absent a deployed lineage-keyed counter, no per-Mission counter, however many Missions in a lineage carry one, adds up to an aggregate bound on the lineage. This document is experimental (Section 2), so a deployment running only the stable issuance and runtime profiles has no lineage-wide aggregate bound in force at all. A deployment MUST NOT render, in an Enforcement Scope Statement or at any consent surface, a lineage-wide or subtree aggregate bound as in force unless a lineage-keyed budget identifier and shared counter meeting this section's requirements are actually deployed and metered.¶

An aggregate bound is deployment policy: it is carried on no single Mission Intent, is committed by no intent_hash, and is disclosed through the deployment's Enforcement Scope Statement rather than the approval event. A refusal under an aggregate bound is carried as quota_exceeded, and its Decision Evidence metering entry records the aggregate key class in counter_scope and the counter in counter_id (Section 10).¶

Aggregate keying crosses the family's per-Mission consistency domains: a subject-keyed or lineage-keyed counter is shared by every Mission the key spans, so it cannot be sharded by Mission Identifier and is provisioned as its own consistency domain ([I-D.draft-mcguinness-mission-runtime]).¶

10. Metering Evidence

A metered decision is auditable only where the evidence exposes the counter state the decision asserted. This document defines one coordinated evidence member, metering, carried in Decision Evidence and Execution Evidence under the runtime evidence companion's extension conventions ([I-D.draft-mcguinness-mission-runtime-evidence]).¶

metering:

An array of one or more entries, one per bound the evaluation metered. In a deployment claiming this profile, a Decision Evidence record emitted for a metered evaluation, permit or refusal, MUST carry it, and an Execution Evidence record MUST carry it where the committed quantity is conveyed by consumed (Section 11.1.1). Each entry has the members:¶

bound:

REQUIRED. A string. The metered bound: a controls member name (Section 6) or the applicable per-entry constraint name (Section 7).¶

counter_scope:

REQUIRED. A string. The counter's key class: mission for the Mission-keyed bounds of this document, or subject, client, or lineage for an aggregate bound (Section 9).¶

counter_id:

REQUIRED. A string. A stable identifier of the counter, the same value on every record the counter's decisions and settlements produce. It is committed or pseudonymous: a sensitive key (a subject or lineage identifier the record does not otherwise carry) appears only as a commitment, for example a sha-256: digest of the deployment's counter key, never raw.¶

requested:

REQUIRED in Decision Evidence, absent otherwise. The quantity the evaluation sought to consume, in the bound's native unit shape: {amount, currency} for max_budget, an integer count for max_calls, an ISO 8601 duration for max_duration, and an object of bytes and messages for max_egress_volume.¶

reserved:

CONDITIONAL. The same shape. The quantity reserved; REQUIRED in the Decision Evidence of a permitted action under a reserving posture (Section 7.2).¶

remaining:

REQUIRED in Decision Evidence, absent otherwise. The same shape. The counter's remaining quantity after the decision; after a refusal, the unchanged remaining quantity the request exceeded.¶

consumed:

CONDITIONAL. The same shape. Execution Evidence only: the actual quantity for the PDP to commit, per the bound-class conveyance rules of Section 11.1.1.¶

settlement_state:

CONDITIONAL. A string. Decision Evidence of a permitted metered action only: the decision-time posture, reserved or committed (Section 7.2). The terminal disposition, commit, release, hold, or conflict, is applied under Section 11.1.2 and joined through evaluation_id; it is not restated in the immutable record.¶

The member turns a metered refusal into a checkable claim rather than an assertion: the refusal's entry shows requested exceeding remaining on a named counter, and the counter's accounting history is the join of the entries sharing its counter_id. A lineage-wide refusal under an aggregate bound reads:¶

{
  "metering": [
    {
      "bound": "max_budget",
      "counter_scope": "lineage",
      "counter_id":
        "sha-256:t7RnQ2xV9kM4wB1sJ6eL3yP8cA5fH0dZu2gN7bXq4Ss",
      "requested": { "amount": "25.00", "currency": "USD" },
      "remaining": { "amount": "10.00", "currency": "USD" }
    }
  ]
}

11. AuthZEN Binding

Where the runtime deployment uses the AuthZEN binding ([I-D.draft-mcguinness-mission-authzen]), this section defines the wire representation of metering. It defines no new metering semantics and no new constraint. The requirements of this section and Section 11.1 apply only to a deployment that adopts the AuthZEN binding under that profile's conformance; for every other deployment the AuthZEN profile remains an informative reference.¶

When metering a bound would exceed it, the PDP MUST deny with quota_exceeded ([I-D.draft-mcguinness-mission-authzen]) instead of returning a permit. The PDP MUST record quota_exceeded as the denial_reason in Decision Evidence.¶

Whether a metered permit is reserved at decision time and committed on settlement, or committed at decision time, follows the deployment's documented reserve/commit posture (Section 7.2); this binding fixes neither. In a batch (boxcar) evaluation, consumption metering applies per item in request order. The exactness of the bound is the consistency bound of Section 7.1, not a property of this wire binding.¶

{
  "subject": {
    "type": "user",
    "id": "user_3p2q8mN1a0kV7tR",
    "properties": {
      "iss": "https://idp.example.com"
    }
  },
  "resource": {
    "type": "ledger",
    "id": "ledger_main"
  },
  "action": { "name": "reconciliation.run" },
  "context": {
    "mission": {
      "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
      "issuer": "https://as.example.com",
      "authority_hash":
        "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
      "state": "active"
    },
    "actor": { "client_id": "s6BhdRkqt3" },
    "credential": {
      "issuer": "https://as.example.com",
      "expires_at": "2026-11-02T09:14:00Z"
    },
    "audience": "https://erp.example.com",
    "freshness": {
      "mode": "fresh",
      "freshness_at": "2026-11-02T08:44:00Z"
    },
    "prior_evaluation_id": "dec_0Rt5nB8xW2qK7mJ4vS1pL9eYc"
  }
}

12. Conformance

A runtime deployment that claims this profile MUST:¶

• meter every consumption bound a governed Mission carries per Section 7, within its documented runtime enforcement scope ([I-D.draft-mcguinness-mission-runtime]);¶

• refuse a consequential action that would exceed a bound, and refuse on any bound it cannot meter;¶

• enforce every consented exclusivity group with a latch atomic with the permit (Section 8);¶

• where aggregate bounds are configured, meter and disclose them per Section 9;¶

• emit the metering evidence member on the records Section 10 requires;¶

• publish its consistency bound under a multi-PDP topology (Section 7.1);¶

• define and document its retry, idempotency, and reserve/commit posture (Section 7.2); and¶

• where the AuthZEN binding is in use, implement the settlement exchange of Section 11.1.¶

A Mission Issuer in a deployment claiming this profile MUST carry the consented bounds on the Mission record committed by intent_hash. It MUST render them at the approval event per Section 6.1.¶

13. Security Considerations

Consumption bounds limit the blast radius of a compromised or runaway agent in a dimension authority narrowing cannot: a Mission whose every action is individually authorized can still be drained by volume. Their enforcement, however, is only as good as the metering:¶

• Unenforced bounds are consent theater. A bound rendered at approval but not metered anywhere misleads the Approver about the Mission's exposure. The consent-integrity rule (Section 6.1) exists for this: it forbids a deployment that cannot meter a bound from rendering it as enforced.¶

• Distributed undercounting. Under a multi-PDP topology, an attacker who can spread actions across decision points exploits the consistency gap. The published consistency bound (Section 7.1) is the honest statement of that exposure; per-PDP sub-budgets bound it structurally.¶

• Settlement honesty. The PDP commits what the PEP reports. Execution Evidence is integrity-protected and signed by the PEP ([I-D.draft-mcguinness-mission-runtime-evidence]); a compromised PEP can under-report duration or spend, which is within the runtime profile's trusted-base assumptions for PEPs.¶

• Lease abandonment. An agent that stops renewing a duration lease and keeps acting is stopped by the PEP, which Section 7 requires to stop the action or obtain a new permit before the lease is exhausted.¶

• Reservation starvation. An attacker who opens reservations and never settles them can consume a budget with no executed action, denying the Mission its remaining authority. The bounded reservation lease (Section 11.1) caps this: an unsettled reservation is reconciled on lease expiry rather than held indefinitely, and the idempotent-release path returns the budget.¶

• Latch burning. Because the first matching action latches an exclusivity group, an injected agent can try to burn a group by driving the side it wants foreclosed, denying the Mission the other side. Releasing the latch on affirmative non-execution (Section 8) keeps an unexecuted attempt from foreclosing the group permanently.¶

14. Privacy Considerations

Metering state (spend, call counts, activity durations) is a fine-grained record of Mission activity over time. It SHOULD be retained under the same access controls and retention windows as runtime enforcement evidence ([I-D.draft-mcguinness-mission-runtime]), and disclosed in decision responses only as refusals, not as remaining-balance oracles. The metering evidence member records remaining inside those access-controlled records (Section 10), never in a decision response.¶

The refusal boundary is itself a coarse balance oracle: the point at which a bound flips from permit to refusal reveals the remaining margin. A deployment SHOULD bound this probing with the AuthZEN profile's denial-oracle controls ([I-D.draft-mcguinness-mission-authzen]), per-Mission rate-limiting of access requests and evidence-logging of request provenance, so a compromised agent mapping a balance by repeated probes is visible to the humans adjudicating it.¶

15. IANA Considerations

This document has no IANA actions. max_budget, max_calls, max_duration, max_egress_volume, and exclusive are Mission Intent controls members defined by this profile under the issuance profile's controls extension seam; context.prior_evaluation_id is AuthZEN extension data carried per the AuthZEN profile's conventions ([I-D.draft-mcguinness-mission-authzen]); measured_duration and metering are coordinated evidence members under the runtime evidence companion's extension conventions ([I-D.draft-mcguinness-mission-runtime-evidence]).¶

16. References

Acknowledgments

This document is part of the Mission-Bound Authorization work and defines its experimental consumption-metering layer.¶

Author's Address