Quantitative mandate sized from the observed value, not the maximum executable effect

Description

This weakness names a gap between the value a quantitative ceiling is checked against and the value the submitted action can actually cost once it executes. A gate derives a checked cost from a live measurement taken at the moment of authorization, a market quote, an index price, a conversion rate, and treats that measurement as the action's cost. When the submitted action itself carries a further parameter capable of producing a higher cost at execution, a limit price above the quote, a maximum acceptable rate, a cap the actor is willing to pay, the gate's own arithmetic ignores it, so an action whose observed cost fits the ceiling can still be executable for materially more. The gap takes either of two concrete shapes, both evidenced by the same underlying case: the execution bound parameter can be missing entirely from the normalized object the ceiling check reasons over, despite reaching the executor unchanged through a separate forwarding path, or the parameter can be present in that object while the arithmetic that derives the checked cost never compares against it. This weakness differs from budget authorization treated as effect authorization, AEW-030: there, a co signer's policy never examines a field with its own independent, separate authority consequence, such as a persistent account delegation, that happens to sit inside the same signed object as a payment already being checked; the omitted field bears on an effect unrelated to the value the policy was written to bound. Here, the parameter in question bears on the identical quantity the ceiling is trying to bound, the action's own cost, and the gap is that the ceiling's arithmetic uses a smaller basis than the action's own terms permit, not that an unrelated effect rides along unexamined. It differs from the agent controls whether its control applies, AEW-004: there, a parameter that disables or bypasses a control entirely is reachable by the acting system, sometimes through a composing tool that forwards arguments unfiltered; the question is whether the control runs at all. Here the control always runs and always produces a decision; what is wrong is the number the decision is computed from. It differs from representation dependent authorization, AEW-020, and from declared capability not surviving executor argument grammar, AEW-025: both of those concern a single check misclassifying or losing an action's own intended meaning through an alternate encoding or a grammar mismatch at the executor. Here the check classifies the action correctly and computes a real number; the number is simply derived from the wrong basis. It differs from enforcement wired to the caller rather than the shared executor, AEW-028: there, some callers of one shared function receive zero enforcement because a check sits in only one caller's own code path rather than in the function every caller shares. Here, every path that can submit the action receives a real, computed authorization decision; the arithmetic behind that decision is simply incomplete.

The authority gap

The authority presented is authority to spend up to a fixed ceiling, priced from the current, observed state of the market at the moment of authorization. The authority required is authority to spend up to that ceiling as measured by the largest cost the submitted action's own parameters could produce at execution, and the two are silently treated as the same fact when the action itself specifies a higher executable bound.

Failure conditions

• A numeric authorization ceiling exists, a maximum notional, spend or exposure cap, and a gate computes the action's cost from a live, observed measurement rather than from the action's own execution bound parameters.
• The submitted action itself carries a parameter, a limit price, a maximum acceptable rate, a cap the actor is willing to pay, capable of raising the actual cost above the observed measurement, and the executor honors that parameter when the action runs.
• That parameter is either absent from the normalized representation the ceiling check reasons over, despite reaching the executor unchanged through a separate forwarding path, or present in that representation without being used as the basis for the ceiling arithmetic.
• Nothing distinguishes an action whose observed cost fits the ceiling from an action whose maximum executable cost does not.

Consequences shown by the evidence

• An action executes, or is forwarded for execution, for materially more than the quantitative mandate was set to permit, because the ceiling was checked against a smaller, observed value rather than the larger, executable one.
• A security or compliance review confirming the checked value falls inside the ceiling finds nothing wrong, because the review inspects the same incomplete representation the gate itself used.
• The identical submitted action can be denied on one execution surface and allowed on another, when only one surface's gate derives cost from the full execution bound parameter set.

Detection signals

• A quantitative cap's sizing logic reads a live quote, index or rate but never reads a limit, cap or maximum acceptable rate parameter the identical action can carry.
• An extractor or normalizer that maps a raw request into the object an authorization gate reasons over lists specific parameter names it maps and omits a parameter the executor's own schema still accepts and forwards.
• Two independent implementations of what is meant to be one enforcement rule, a direct SDK path and an MCP or API gateway path, compute a bounded value from different formulas for the identical action type.

Known examples

• Vibe-Trading (HKUDS/Vibe-Trading), an open source LLM agent trading framework, enforces a per-order notional ceiling, max_order_notional_usd, on live broker orders through two independently maintained gates: a direct-SDK gate (src.live.sdk_order_gate) and an MCP gate (LiveOrderGuardTool in src.live.order_guard, wrapping a connected broker's own MCP order-placing tool). Both gates size a quantity-only order's notional by multiplying the requested quantity by a price. Before pull request 1312, merged 1 September 2026 as commit 789ca2b1, the direct-SDK gate's _implied_notional priced every quantity order, including a buy limit, from the live quote alone. Because a buy limit is fillable at any price up to its own limit, a limit set above the quote let the broker fill for more than the quote-derived notional the gate had checked. Pull request 1312 fixed this by adding a limit_price field to the shared OrderIntent object every gate reads, and pricing a buy limit at the larger of the live quote and the submitted limit price, leaving a sell limit priced at the quote since a sell limit does not create additional exposure. Before pull request 1361, merged 6 September 2026 as merge commit 07ad49f888c7ef658c773eeba4eb0a278d3bc8ea, the MCP gate carried the identical gap through two separate omissions rather than one. The Robinhood connector's own extract_order_intent, which turns the MCP tool call's raw keyword arguments into an OrderIntent, never read a limit_price keyword argument at all, so an OrderIntent reaching order_guard's own notional check never carried a limit price even though limit_price was, by then, already a defined field on OrderIntent following pull request 1312. Separately, order_guard._normalize_intent_notional, the function that derives a quantity order's enforced notional, multiplied quantity by the live quote alone, with no comparison against any limit price. Because the MCP tool wrapper forwards to the broker every keyword argument its schema allows, limit_price itself still reached Robinhood's own place_equity_order call unchanged. Only the authorization decision, not the forwarded order, was missing it. A reproduction added in pull request 1361 and independently re-run for this record against both the pre-fix and the fixed commit: a mandate capping max_order_notional_usd at 750 dollars, a live quote of 100 dollars, and a submitted order of 5 units at a 200 dollar buy limit produced an ALLOW decision sized at 500 dollars, 5 units times the 100 dollar quote, with the full order, including the 200 dollar limit, forwarded to the broker's own place_equity_order call. The broker's own execution semantics permit a limit order to fill anywhere up to its limit, for a maximum executable notional of 1,000 dollars, 33 percent above the 750 dollar mandate. Running the pull request's own added tests directly against a local checkout of the pre-fix commit (cc4774ed) for this record showed 8 of the 29 new or modified assertions fail, including the exact 750/100/200 dollar scenario, which returns an allowed order rather than a blocked one; running the identical tests against the fixed commit (74c16db6) showed all 29 pass. The same extractor treats a present but unparseable, non positive or non finite limit price, including float overflow and the literal string inf, as an ambiguous order and denies it, rather than falling back to quote-only pricing, so a malformed execution bound parameter fails closed instead of silently reverting to the smaller, observed value. Pull request 1361's own merge commit message states plainly that the MCP path carried, in its own words, dead plumbing: OrderIntent already carried limit_price after pull request 1312, but nothing on the MCP path read or set it until this second fix. As of this record, Vibe-Trading registers only one broker, Robinhood, against the MCP gate's own extractor lookup table, so the same gap for any other broker's MCP order-placing tool, and any stop price or comparable trigger field a broker schema might expose, remains unestablished rather than assumed absent.

Recorded instances

• AEV-2026-0046 Vibe-Trading's MCP live order gate priced a buy limit order at the quote alone, five days after the identical gap was fixed on the direct SDK path AESS 6.2 medium Confirmed

Related Intelligence Records

The published Moona Intelligence Records whose evidence establishes this weakness.

• The Mandate Capped the Trade at $750. The MCP Gate Approved an Order the Broker Could Fill for $1,000.

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.

• Missing requirement

  Agent Action Decision Protocol (AADP)

  Shamik Saha, individual submission to the IETF

  Requirement Concurrent requests must not independently consume the same remaining budget

  AADP's own described atomic budget reservation answers a concurrency question: whether two simultaneous requests can each believe they consumed the same remaining unit of a budget. Vibe-Trading's own MCP gate defect is not a concurrency failure; a single order, evaluated once, was priced against the wrong basis value. Nothing in AADP's own described budget accounting, as corroborated here, states that a reserved amount must itself be derived from the maximum executable cost a submitted action's own parameters permit, as distinct from correctly reserving whatever amount a caller declares. Recorded as a requirement this dataset's evaluated protocols do not currently name, not as a defect in AADP's own atomic reservation mechanism, which answers a different, real question.

  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 described canonical transaction digest binds a named amount field to both approval and execution, which is a real answer to a digest disagreeing with itself after the fact. It is not, on the material this dataset corroborates, an answer to whether the bound amount itself already reflects the largest value the action's own other submitted parameters could produce at execution. Vibe-Trading's own pre-fix MCP gate demonstrates exactly that gap outside any digest scheme: the notional the gate approved, 500 dollars, was faithfully the value its own arithmetic computed, and the binding between that approved value and the forwarded order was never in question. What was missing was a requirement that the approved value itself be derived from the order's maximum executable cost, 1,000 dollars once the submitted limit price is accounted for, rather than from the live quote alone. Recorded as a requirement this dataset's evaluated protocols do not currently name, not as a defect in ChainIT's own digest binding, which this record does not treat as deployed here.

  View protocol evidence