Intelligence
Join the waitlist
AEW-030

Budget authorization treated as effect authorization

A co signer evaluates a compound signed object's cost relevant fields, gas, fee and validity among them, before producing a signature that legally covers the entire object. A further field the same object can carry, with its own persistent authority consequence, is never evaluated, and fitting inside the approved cost ceiling is treated as though it were also inside the approved authorization.

Status: publishedApproval ControlsExecution AuthorityDelegated Authority

Description

This weakness names a gap between two decisions a single signing act can quietly collapse into one. The first decision is whether a proposed payment's cost, gas, fee, validity window and similar fields, falls inside a sponsor's or co signer's configured budget. The second, separate decision is whether every other consequential effect the same signed object carries, including a field the budget check was never written to examine, is something the signer actually authorized. A budget check can pass honestly, every field it inspects is genuinely inside policy, while a second, entirely separate field sits unexamined in the identical object, because the object's format allows more fields than the policy's own author anticipated when the check was written. This weakness differs from objective authorization treated as action authorization, AEW-002: there, an agent holding authority over an outcome chooses an unanticipated action to reach it, and the authority gap is the agent's own choice of means; here, the acting system is the co signer itself, no outcome was ever authorized to begin with for the unevaluated field, and the gap opens because a field the policy never names is present at all, not because of how a goal was pursued. It differs from approval not bound to the executed action, AEW-005: there, what was reviewed and what executes diverge because state changes, or the approval's own scope is undefined, between one moment and another; here, nothing changes between review and execution, the reviewed object and the executed object are the identical, unmutated signed bytes, and the gap is that the review's own field coverage was narrower than the object it produced a binding signature over. It differs from authorization over an operation treated as authorization over its target, AEW-013, and from authority over a reference treated as authority over the shared resource it resolves to, AEW-014: both of those concern one resource identity standing in for another inside a single authorization check; here there is no substitution of one resource for another, only a field the check never looked at, sitting beside the fields it did.

The authority gap

The authority presented is authority to approve a payment's cost within a bounded budget. The authority required is authority over each consequential effect the same signed object carries, including a persistent effect a budget check never inspects, and the two are silently treated as the same fact.

Failure conditions

  • A co signer or sponsor evaluates a compound signed object's cost relevant fields before producing a signature that legally covers the complete object, not only the fields it inspected.
  • The same signed object format allows a further field with its own, independent persistent authority consequence, such as a delegation or a credential grant, distinct from the payment the cost check evaluates.
  • The policy applies no explicit rule, allow or deny, to that further field, so its presence or absence never affects whether the object is signed.
  • Nothing distinguishes an effect that merely fits inside the approved cost ceiling from an effect the policy actually decided to authorize.

Consequences shown by the evidence

  • A sponsor's own signature pays for and legally co authorizes a persistent account delegation or a persistent credential it never evaluated, because the cost of doing so fit inside a gas or fee ceiling the policy did check.
  • A security review that confirms a payment's amount, recipient and fee are all within policy finds nothing wrong, because those are the only fields the policy was ever written to check, while a further field with its own persistent effect sits unexamined in the same object.
  • A persisted delegation or credential continues to exist and to be usable after the payment that funded it has settled, independent of anything the payment's own budget check evaluated.

Detection signals

  • A payment or cost approval policy enumerates specific numeric or budget fields to check and applies no rule to any other field the same signed object format defines.
  • A co signed transaction's actual executed effect includes a persistent state change, such as a delegation or a new credential, with no policy log or decision record showing it was evaluated.
  • Documentation or source comments describe a policy as bounding cost or spend without describing what happens when the signed object carries a field outside that description.

Known examples

  • CVE-2026-82750, published 6 September 2026 against ZenHive's mpp, an Elixir implementation of the Machine Payment Protocol for AI agent and machine to machine commerce. Its Tempo fee payer policy, MPP.Methods.Tempo.FeePayerPolicy.measure and validate, bounded a sponsored transaction's gas limit, maximum fee, validity window and access list before co signing it, and never read the same transaction's EIP 7702 authorization list, independently corroborated search results naming the field tempo_authorization_list in one account of the advisory and aa_authorization_list in another. Each signed entry in that list is charged to the sponsor as intrinsic gas and persistently upgrades the client's own account to delegated, smart contract style code. The reporter's own reproduction, seven delegations, moved the transaction's cost from about 46,575 gas to about 1,884,087 gas, roughly forty times higher, entirely inside every field the policy did check.
  • CVE-2026-82751, published the same day against the identical policy in the same package, addresses an independent field: an optional key_authorization field the transaction envelope can carry, which the policy also never inspected. A signed key authorization causes the sponsor to pay the intrinsic gas and storage cost of provisioning a new access key, scoped by whatever limits the client attached, on the client's own account. The reporter's own reproduction, one key plus three token spending limits, moved the cost from about 46,587 gas to about 1,808,700 gas, roughly thirty nine times higher. Both CVEs affect mpp from 0.2.0 before 0.16.1 and are fixed in 0.16.1, whose commit 0482572b47e1ffe1537ab80ab613d47b92833c2d adds an authorization list check rejecting any non empty list and failing closed on a malformed one, and a key authorization check rejecting the field unless a sponsor has explicitly pinned an expected value to compare it against exactly, both wired into the same validate path that produces the sponsor's co signature.
  • A paper submitted to arXiv on 31 August 2026, The Irreversibility Budget: Fleet-Level Risk Accounting and Admission Control for Agent Operating Systems (arXiv 2609.00275) by Bardia Mohammadi and Laurent Bindschaedler, names the same collapse from the accounting side rather than the field coverage side this weakness's own known examples above evidence: a cumulative risk budget correctly enforced against the numbers it is given is not the same claim as those numbers being trustworthy. Corroborated across search since arxiv.org was blocked at this session's network egress proxy on every attempted route, the paper states its own central limitation plainly: effect pricing is hard, because effects are heterogeneous, adversarially declared, and correlated, so a misdeclared or underpriced effect, or an unmodeled correlation the ledger treats as independent, can let a technically correct budget check believe itself safe while realized loss exceeds the tolerance it was built to hold. This session cloned and read the reference implementation directly at github.com/mpi-dsg/irreversibility-budget: a checked-in 300-run simulator includes a named misdeclaration attack arm (e1_budget_attack_misdecl) alongside its enforced-budget baseline, evidence the paper's own evaluation treats declared-versus-actual effect pricing as a distinct threat surface from the admission logic itself. This is controlled simulation evidence, not a formally assigned CVE against shipped software, and this entry does not treat it as equivalent in evidentiary weight to the two CVEs recorded above.

Protocol evidence

Published authority architectures whose artifacts bear on the requirement this weakness names: which satisfy it, which expose a way past it, and which leave it unanswered.

  • Supports requirement

    ChainIT Authority Protocol and Agent Subject Profile for pre execution authority validation

    ChainIT

    Requirement ChainIT states access to an organization or a Pactvera does not automatically authorize every action

    ChainIT's own stated principle that access to an organization or a Pactvera does not automatically authorize every action is exactly the principle both ZenHive CVEs validate from the opposite direction: a sponsor's own access to co sign and pay for a transaction did not, on ChainIT's own stated doctrine, automatically authorize funding a persistent EIP 7702 delegation or a persistent key authorization riding inside the same signed object. This dataset treats both formally assigned CVEs as independent, real world evidence supporting the continued need for ChainIT's own stated requirement, distinct from any claim that ChainIT's own architecture implements or enforces it.

    View protocol evidence

  • Missing requirement

    Agent Authorization Envelope (AAE)

    L. K. Kroehl, CryptoKRI GmbH, individual submission to the IETF

    Requirement MANDATE defines permitted purpose, action patterns and delegation rules

    AAE's own reported MANDATE block defines a permitted purpose and allowed action patterns, distinct from CONSTRAINTS, which bounds a mandate with concrete numeric limits such as a spending ceiling. ZenHive's own fee payer policy implemented only a CONSTRAINTS style budget check, gas, fee, validity and access list, and named no MANDATE style action pattern distinguishing a plain payment from a payment that also carries an EIP 7702 authorization list or a key authorization entry. Had an equivalent MANDATE block been evaluated alongside the budget, either additional field would have needed its own permitted action pattern rather than merely fitting inside a cost ceiling. Recorded as a requirement this dataset's evaluated protocols name in the abstract but that ZenHive's own fee payer policy did not implement, not as a bypass of AAE itself, which this record does not treat as deployed here.

    View protocol evidence

  • Missing requirement

    ChainIT Authority Protocol and Agent Subject Profile for pre execution authority validation

    ChainIT

    Requirement A canonical transaction digest is described binding payer, payee, destination, amount, currency or asset and payment rail to approval and execution

    ChainIT's own reported canonical transaction digest binds payer, payee, destination, amount, currency and payment rail to one approval, but its own reported field list, as corroborated here, names payment fields rather than every effect bearing field a signed transaction envelope can carry. Nothing corroborated for ChainIT's own material states that its digest, or an equivalent binding, covers a persistent authority bearing field such as an EIP 7702 authorization list or a key authorization entry riding alongside a payment inside one signed object. Both ZenHive CVEs demonstrate exactly the gap this property does not yet close: a bounded payment field set was evaluated correctly while a further, independently effect bearing field in the same object was not evaluated at all. Recorded as a requirement this dataset's evaluated protocols do not yet extend to a fee payer's own multi field envelope, not as a bypass of a requirement ChainIT does state.

    View protocol evidence