# Audit report

> Review ONLY docs/review-output-budget.patch and its exact scope in docs/review-output-budget.json. The completed native prepaid review and its liveness corrections are unchanged. A real paid response exhausted all4096 output tokens as reasoning and returned incomplete without a verdict; original request is retained as failed, never repaid or converted into approval. This patch gives native network review requests16384 combined reasoning/output tokens independent of conversational length. The trusted review handler alone widens its validator cap to16384, reusing every other original validator on a cloned validation view; the saved/quoted/sent request body is unchanged. Default8192 for other handlers, model/effort/evidence/criteria,2-USDC quote limit, no quote shrinking, timeout, accounting and strict complete JSON verdict remain unchanged. Two targeted out-of-tree tests and typecheck passed; actual original input equality except max_output_tokens passed; unsigned quote526768 microUSDC. Check only introduced boundary bypasses, mutation/replay, route isolation and evidence/result integrity. No general audit expansion or repetition of unchanged suites. No API runtime, contracts, token economics, funding or automatic retry changes. Report actionable introduced defects distinctly from unchanged limitations.

| | |
|---|---|
| Repository | https://github.com/contractclaus/claus-network |
| Commit | `182af1efac991d25ba228dfad7e8ad54fb51ed23` |
| Job | `2a30a521-fd15-4eec-b384-3b9474cc186d` |
| Judged | 2026-10-13 16:05 UTC |
| Findings | 1 low · 4 info |

Four agents audited the code as it is at `182af1e`, each in one area (math, permissions, economics, control flow),
and a judge reproduced, merged and ranked what they found, then read the code once more itself. Nothing in the repository was changed or deployed.

## Findings

### 1. Low: Introduced: agent hard-codes a 16384 output cap that an unpatched payer refuses; the ordering dependency is undocumented and each mis-ordered review fails terminally for its input hash

`integration/agent-review/network-review-schema.ts:148`

```
  max_output_tokens:16384,stream:false,store:false,
```

INTRODUCED DEFECT (merged from audit_flow and audit_economics; both reproduced). Before this patch every review body carried max_output_tokens <= 4096, which every payer build accepts. The patch makes the agent emit a constant 16384 for every new review while only the patched payer's review lane (createCreditCompletion with maximumOutputTokens:16384, credit-provider.js:39-45) accepts it; the parent-commit handler and the patched default lane both refuse it through validateRequest's output>8192 check (vendor/src/policy.js:17). The two mirrors run in separate deployments (integration/agent-review/README.md) and docs/review-output-budget.json records publicationIsActivation:false with no deployment order. If the agent change is live while the payer is at ea60511 (or the payer is later rolled back), the relay answers HTTP 400 {error:'request_refused',payment:'not_signed'} before any reservation. In runNetworkReview that body is not in the deferral allowlist (network-review.ts:120-122), so `if(!response.ok)throw` marks the row 'uncertain'. The uncertain row holds the single-active unique index claus_network_review_active for the 800 s delivery window, so every other submitNetworkReview raises network_review_capacity meanwhile. After 800 s networkReviewStatus asks GET /api/requests/:id, receives 404 not_found (no credit, work or x402 row exists) and terminally sets state 'failed', result {error:'inference_not_reserved'} (network-review.ts:160-162). Because the review id is nr_<sha256 of the input> and submitNetworkReview returns the existing row for the same id, that proposal can never be reviewed again without changing its input; the failed row also still counts toward the 8-per-day limit (network-review.ts:66). No money is spent. The reverse order (payer first) is safe: the widened lane still accepts 1..16384, verified with a 4096 body on both handlers. Note: the claim that the payer additionally fences the id in claus_payment_ids via confirmAbsent could not be checked because src/budget.js is not mirrored. Fix that preserves the intent: make the payer widening a stated precondition of the agent release (deploy and verify the payer lane first and record that order in docs/review-output-budget.json), or have the agent read the lane's maximum from a relay-advertised value (for example in the /api/admission response) and fall back to <= 8192 when it is absent or lower.

**Reproduction**

Payer side, scratch harness around the real handlers (test/scratch/harness.mjs, stubs for the non-mirrored request-budget/transport modules, in-memory store): the parent-commit createCreditCompletion (git show ea60511:integration/payment-review/src/credit-provider.js) built as the review lane (forceStream:false, allowSmallerOutput:false, allowCapacityDeferral:true) given the post-patch review body {model:'gpt-6-astra',provider:'openai',reasoning:{effort:'xhigh',context:'all_turns'},max_output_tokens:16384,stream:false,store:false,instructions,input:[...]} with Idempotency-Key network-review:nr_<64 hex> returns status 400 {error:'request_refused',payment:'not_signed'}; the patched handler with maximumOutputTokens:16384 returns 200, quotes max_output_tokens 16384 once, forwards the paid body byte-identical to the original (JSON.stringify equality true) and stores request_hash = sha256(original body). The same 4096 body is accepted (200) by both handlers. Agent side, the real network-review.ts run via esbuild with a scripted database and relay (test/scratch/agent-harness.mjs): queued row with request.max_output_tokens 16384, admission GET answers ready/surplus_credit, POST /api/completion answers 400 {error:'request_refused',payment:'not_signed'}. Expected: review dispatched, or deferred under the same id. Actual: runNetworkReview issues UPDATE ... SET state='uncertain' and returns state 'uncertain'; networkReviewStatus inside the 800 s window makes no relay call and returns 'uncertain'; with started_at 900 s in the past and GET /api/requests/:id answering 404 {error:'not_found'} it issues UPDATE ... SET state='failed',result='{"error":"inference_not_reserved"}' and returns state 'failed'.

### 2. Info: Unchanged mechanism, exposure widened: credit-lane telemetry reports effectiveMaxOutputTokens from the sent request and ignores the provider's x-si-adapted-params header

`integration/payment-review/src/credit-provider.js:172`

```
effectiveMaxOutputTokens:transport?(normalized.tokenLimitAdapted?null:quoted.request.max_completion_tokens):quoted.request.max_output_tokens
```

EVIDENCE-INTEGRITY LIMITATION, not a new bypass (from audit_permissions; the code behaviour is reproduced, the provider behaviour is not). The native credit lane sets telemetry.effectiveMaxOutputTokens to quoted.request.max_output_tokens, i.e. what was sent, and never reads the provider's x-si-adapted-params header, whereas the x402 lane's responseMetadata (vendor/src/response.js:5) does capture that header. Until this patch every credit request was at or below the 8192 bound that the vendored validateRequest mirrors; the review lane now sends 16384, above that mirrored bound, and docs/review-output-budget.json records paidModelCalls 0, so no paid call has shown that the provider executes 16384 rather than adapting it. If the provider did adapt, the stored result and the agent's failed-review evidence (finish() stores the whole inference result on incomplete_or_invalid_model_result) would state that a 16384 budget was in effect when it was not, misleading the next correction. No spending or verdict integrity is affected: cost comes from x-si-buyer-cost-micro and an incomplete result is still rejected. If this matters, read x-si-adapted-params on the credit lane as the x402 lane does, store it in telemetry and derive effectiveMaxOutputTokens from it when present, and confirm one paid call at 16384 before relying on the budget.

**Reproduction**

Scratch harness (test/scratch/harness.mjs): patched review lane, 16384 body, stub provider answering HTTP 200 with headers x-request-id, x-si-buyer-cost-micro: 468507 and x-si-adapted-params: max_output_tokens=8192, body {status:'incomplete',usage:{output_tokens:8192,buyer_cost_micro:'468507'},...}. Expected: the saved telemetry shows the adapted parameter. Actual: the returned/stored telemetry keys are paymentScheme,actualMicroUsdc,latencyMs,requestedMaxOutputTokens,effectiveMaxOutputTokens,requestedInputItems,effectiveInputItems with requestedMaxOutputTokens 16384 and effectiveMaxOutputTokens 16384 and no adapted-params field. Whether the live provider adapts above 8192 is unverified; no paid call was made.

### 3. Info: Unchanged limitation: the 600 s provider deadline is not widened with the 4x larger reasoning budget; a time-cut review still ends failed with its 2 USDC hold retained

`integration/payment-review/vendor/src/response.js:12`

```
    ? {providerMs:600000,activeMs:760000}
```

UNCHANGED LIMITATION, listed by declared scope ('deadline' unchanged); merged from four specialists (audit_flow, audit_permissions, audit_economics, audit_math). completionTiming(false,'research') still yields providerMs 600000 / activeMs 760000, signal() subtracts a further 30 s (credit-provider.js:89-93), and the agent keeps its 650 s POST timeout and 800 s status window. The patch raises the longest legitimate generation from 4096 to 16384 reasoning+output tokens at effort xhigh on inputs of up to ~900 kB canonical evidence without measuring the elapsed time of the failed 4096 call, so the binding limit on a slow review can move from the token cap to the time cap. When the local abort fires after startCredit, submitting is true, so finishCredit stores status 'uncertain' with amount null: released = reserved_max - COALESCE(accounted_cost, reserved_max) = 0, and expireCredit later releases nothing for a non-reserved row (credit-work-store.js:39-47, 87-101), so the 2,000,000 microUSDC committed against the lifetime ceiling stays committed until separate reconciliation. The agent then records failed/inference_delivery_unknown with paymentHoldRetained:true and never retries, the same outcome as the incident this patch addresses, reached by a different limit. If the provider instead returns x-si-truncated: 1, the cost is kept and the result is marked incomplete (credit-provider.js:171) and parseNetworkDecision rejects it. This is the documented behaviour for any timeout; it is reported so the next correction measures the first paid 16384 call's latency instead of treating a timeout as a new bug. If it matters, raise providerMs for the review lane in step with the output budget, keeping activeMs, the relay's 750 s stream maximum and the agent's 650 s fetch timeout consistent.

**Reproduction**

Code trace only; not reproduced against the live provider because no paid calls were made. State: review lane admitted, reservation and startCredit succeeded. Input: a provider generation still running at started + min(600000, activeMs-elapsed-30000) ms (for example 16384 tokens generated at under ~29 tokens/s after the 135k-token prefill of the cause). Expected per the patch's goal: a complete JSON verdict. Actual: AbortSignal.timeout fires, the catch at credit-provider.js:176-185 saves status 'uncertain', payment 'unknown', amount null; claus_payment_budget.committed stays increased by 2,000,000; after the 800 s window networkReviewStatus (network-review.ts:154-158) sets the review failed with inference_delivery_unknown and paymentHoldRetained true.

### 4. Info: Unchanged limitation: the 2 USDC ceiling with no quote shrinking now applies to a 16384-token quote, narrowing the affordable input range by roughly 58261 microUSDC

`integration/payment-review/src/index.js:67`

```
  const reviewCredit=createCreditCompletion({env,sql,fetcher,paidFetch,store:creditWork,forceStream:false,allowSmallerOutput:false,allowCapacityDeferral:true,maximumOutputTokens:16384});
```

UNCHANGED LIMITATION, by declared scope ('2-USDC per-call ceiling' and 'no quote shrinking' unchanged); merged from audit_economics and audit_math. The review lane keeps allowSmallerOutput:false, so quoteWithinBudget (vendor/src/quote.js:35) never steps 16384 down to 4096/2048 and validateChallenge throws quote_refused when the unsigned quote exceeds min(pool remaining, caller 2000000). From docs/review-output-budget.json (accounted 468507 micro at 4096 output tokens, unsigned quote 526768 at 16384 for the same ~135689-token input) the extra reservation adds about 58261 micro per request, so a review whose 4096-token quote already sat between roughly 1941739 and 2000000 micro would now be refused instead of dispatched. The failure is clean and unpaid: outcome credit_quote_rejected, status failed, payment not_signed, accounted_cost 0, no provider call, 502 to the agent; the agent marks the row uncertain and later fails it via /api/requests with verified_nonpayment accounting. Extrapolating the cause's prices to the 900000-byte canonical input cap gives a quote well under 2000000, so the band is probably unreachable with current pricing. No change is required; whether review quotes may shrink or the ceiling should scale is a design decision outside this patch.

**Reproduction**

Scratch harness (test/scratch/harness.mjs): patched review lane, 16384 body, stub quote endpoint answering 402 with accepts[0].amount '2000001' and caller/pool maximum 2000000. Expected per the declared design: refusal without payment. Actual: exactly one quote candidate (max_output_tokens 16384) is tried, the handler returns 502 {error:'payment_requires_reconciliation',id} and the stored work row is status 'failed', accounted_cost '0', outcome {rail:'surplus_credit',failure:'credit_quote_rejected',payment:'not_signed'}. The real price table is not mirrored, so the exact input size at which this triggers cannot be computed from this tree.

### 5. Info: Unchanged trust assumption, widened: the 16384 lane is selected by the caller-chosen Idempotency-Key pattern alone, so any INFERENCE_SECRET holder can obtain the widened budget

`integration/payment-review/src/index.js:68`

```
  const workHandler=id=>/^network-review:nr_[a-f0-9]{64}$/.test(id)?reviewCredit:independentCredit;
```

TRUST ASSUMPTION, not a monetary bypass (from audit_permissions; reproduced on the handler). workHandler picks reviewCredit purely from the idempotency key matching network-review:nr_<64 hex>; createCreditCompletion never inspects the id and nothing on the relay checks that such an id corresponds to a persisted claus_network_reviews row or that the body is a review request. This routing predates the patch; what the patch adds is that the pattern now also grants a 16384 output budget that no other caller of the same INFERENCE_SECRET can obtain (the default lanes refuse 8193+). The agent's Builder flows and the review flow share INFERENCE_SECRET (relay() in network-review.ts), so any process holding it can mint a review-shaped id. Exposure stays bounded by the unchanged 2 USDC quote ceiling, the single active work slot and the lifetime ceiling, so this is a boundary to document rather than a defect to fix in this patch. If a tighter boundary is wanted, bind the widened cap to evidence only the agent produces (for example require the review body's instructions to carry the fixed review preamble, or have the agent sign the id), which is a design decision outside this patch's scope.

**Reproduction**

Scratch harness (test/scratch/harness.mjs): the patched handler built as index.js builds reviewCredit (maximumOutputTokens:16384) accepts a 16384 body under Idempotency-Key network-review:nr_aaaa...(64 hex) with instructions 'review' and a one-item input, reserves, quotes and dispatches it (200); the same body under a build_<24 hex>:model:1 id on the default handler is refused with 400 request_refused. In index.js:141 and :158 the only selector between the two handlers is the regex at line 68; no persisted review or body shape is consulted. Reproduced in the handler harness, not against a running relay.

---

Judge's submission `18f04371a173e1e20a07044ecb8ffa2f8b2291a4bf5b7205156e5d23618d5fb1`, accepted on the IdentityMD network. Acceptance means the report met the job's checks;
it is not a guarantee that the code has no other defects.