Source-linked AI summary
Correlated Failures of AI Approval Monitors
Luca Zanolini
TL;DR
AI approval monitors can fail together when they share models or evidence, making vote aggregation an uncertain basis for safe decisions. The paper models joint failures and measures monitor behavior on payment approval. Counting sources blocked 0.9% of correct payments versus 7.4% for the best counting rule at equal safety, while the worst-case test failed for language-model monitors alone.
Problem
It is unclear which approval rules remain safe and live when AI monitors can be fooled together through shared models or inputs.
Source: §1 · pp. 1–2Method
Results
0.9% of correct payments were blocked by the source-counting rule, versus 7.4% by the best counting rule at equal safety, but one attack defeated the worst-case condition for twelve language-model monitors.
Source: §1 · p. 2, §9 · p. 18Takeaways & Limitations
Diversifying evidence sources and including a rule engine restored the safe-and-live condition on the measured attacks.
Source: §9 · p. 18The measurements concern payment approval with independently checkable fields, and zeroes bound only the attacks run.
Source: §8.1 · p. 17
Abstract
from arXiv · showhide
Before an AI agent takes a consequential action, such as paying, messaging or changing code, several monitors check it. Their verdicts are combined by aggregating scores or by counting approvals, whatever inputs the monitors share. Monitors that share a base model or a poisoned input, however, may fail together. We borrow the fail-prone systems of distributed computing: lists of monitor sets that may fail together. A rule is safe if it executes no bad action and live if it blocks no good one. We measured twelve small open-weights monitors on payment approval under two pre-registered protocols. Without pre-registration, we also measured three closed frontier models (Claude Opus 5.5, GPT-6 Astra, Gemini 4 Argon) and the open DeepSeek-V3.2. Every reliable fooling of a monitor into approving a fraud came through an evidence source and reached only that source's readers. Fooling it into blocking a correct payment depended on injection resistance, a monitor's refusal to follow instructions planted in its data. Small models and DeepSeek obeyed such notes. The three closed models ignored them in all but one case, and Opus also resisted persuasion tailored to it. On new data, a rule that counts sources instead of votes blocked 0.9% of correct payments, against 7.4% for the best counting rule, at equal safety. The pre-registered worst-case test failed. One attack left the approvers on a single source, so no rule over the twelve language-model monitors survives every measured attack. Adding a rule engine, which cannot be persuaded, restored the condition for a safe and live rule on the measured attacks. Diversify the inputs, harden the monitors, count sources, not votes.
1 Introduction
This section frames monitor approval as a problem of correlated failures and tests how shared evidence and injection resistance shape errors. In payment approval, counting sources reduced false blocks at equal safety, but the pre-registered worst-case test showed that no rule over the twelve language-model monitors survived every measured attack.
1 Introduction
- The study measured both directions of fooling in two pre-registered protocols on twelve small monitors, then ran non-pre-registered frontier-model arms.The pilot refuted a single-list classical theory; the confirmation tested the directional reading suggested by the pilot.Source: §1 · pp. 2–3
- Fraud-approval attacks followed evidence sources: in confirmation, fooled sets were exactly the three source columns, including across the measured frontier-class monitors.No justification text made its target approve more than 8.3% of training frauds, even when the attacker could read token probabilities.Source: §1 · p. 2
- Planted instructions in data made small models across families and DeepSeek-V3.2 block correct payments, while Opus and Astra ignored them and Argon did so in all but one case.Persuasion tailored to Opus fooled none of 640 held-out verdicts; hiding the justification field reduced blocking notes to within 0.05 of the benign floor.Source: §1 · p. 2
- 0.9% of correct payments were blocked by the two-source rule, versus 7.4% by the best counting rule at the same safety.The comparison was made on new confirmation data and was pre-registered and supported.Source: §1 · p. 2
- The pre-registered cross-cover hypothesis failed when one note left approvers on a single source, but adding a rule engine restored the condition in every bootstrap resample.The negative worst-case result applies to the twelve language-model monitors; the thirteen-monitor pool included the rule engine.Source: §1 · pp. 2–3
- Opus refused 30% of correct payments with an apparent tampering trace and none under a neutral line; Astra, Argon, and DeepSeek refused none.These exploratory refusals reached only readers of the tampered-looking source, which the two-source rule absorbed.Source: §1 · p. 3
- The empirical claims concern payment actions whose fields can be checked against independent records, and reported zeroes bound only the attacks run.Monitors check proposed actions against external evidence rather than the agent’s reasoning; the justification was the one agent-text field they read.Source: §1 · p. 3
- The paper adapts fail-prone systems—lists of monitors that may be fooled together—to derive approval-rule conditions for safety and liveness.Its contribution extends classical financial-control ideas by measuring implications for AI monitors and addressing liveness.Source: §1 · pp. 1–3
2 Model and the approval-rule hierarchy
This section models which monitors may be fooled together and uses that structure to characterize approval rules. It relates safety and liveness to cover conditions, distinguishing general rules from counting rules and identifying when no safe, live rule exists.
2 Model and the approval-rule hierarchy
- The model treats monitors as fooled when manipulated inputs or honest errors produce wrong verdicts, and assumes one forwarded action removes equivocation.Attackers control the proposal and some sources, with typed text and poisoned-source budgets; compromised gateways and forged signatures are out of scope.Source: §2 · pp. 3–4
- A fail-prone system lists monitor sets that may fail together; its cover number τ is the fewest listed sets covering all monitors, and Qk means τ > k.A kernel is a set contained in no listed failure set.Source: §2 · pp. 3–4
- For factual checks with a non-equivocating proposer, the kernel rule is safe and live iff Q2 holds; without Q2, no decision rule is both.For judgements or equivocation, agreement requires Q3; self-verifying checks need only Q1.Source: §2 · p. 4
- Counting rules combine nonnegative monitor weights against a threshold, whereas structure-aware rules use the sets of monitors that may fail together.The paper derives failure groups from shared provenance, such as a base model, document or index, operator, or tool.Source: §2 · pp. 4–5
- For factual checks, a safe and live counting rule exists iff τ* > 2, while a rule of any kind exists iff τ > 2.On the pilot provenance grid, τ = 3 and τ* = 2, so the kernel rule is safe and live but no weighted vote is.Source: §2 · pp. 4–5
- On a 3 × 3 grid with one vulnerable row and one vulnerable column, majority executes fraud, the kernel rule is safe and live, and no counting rule is.The grid represents shared base-model families as rows and evidence sources as columns.Source: §2 · p. 5
3 Directional fail-prone systems
The paper models approval and rejection failures separately because attacks can fool different monitor sets in each direction. A safe and live approval rule exists exactly when no approve-fooled set and reject-fooled set together contain every monitor.
Directional fail-prone systems
- Fraud-approval attacks reached only readers of their evidence source, while blocking attacks used justification notes read across sources and fooled whichever models were gullible.The reject-fooled sets were therefore much larger than the approve-fooled sets; pooling both directions made every block-gullible monitor count as fraud-vulnerable.Source: §3 · p. 5
- Cross-cover means every group left approving by a blocking attack is safe, because it is contained in no approve-fooled set.The condition fails if a reject-fooled set leaves approvers all inside one approve-fooled set.Source: §3 · pp. 5–6
- For threshold faults in each direction, the rules fit when n − f ≥ f + 1, recovering the classical condition n ≥ 2f + 1.At n = 2f + 1, the rules coincide and majority is the only safe and live rule.Source: §3 · p. 6
- A safe and live rule exists iff no approve-fooled set and reject-fooled set together contain every monitor (the cross-cover condition).The condition is necessary for every decision rule, including rules that read rejections and use timeouts.Source: §3 · pp. 5–6
- KA is the largest safe rule, refusing approval sets contained in an approve-fooled set; QR is the smallest live rule, executing when approvers include all monitors outside a reject-fooled set.When the cross-cover condition holds, safe and live rules are exactly the up-sets between QR and KA.Source: §3 · pp. 5–6
- Choosing KA requires estimating approve-side failures and then verifying liveness; the measured approve side was small and stable, while reject failures were driven by persuasion.A rule engine or person that cannot be persuaded can restore cross-cover only while the attacker cannot forge every record it checks; estimated failure sets may also grow as attackers find new attacks.Source: §3 · p. 6
4 Measurement
The measurement uses a payment-approval task with monitors arranged by model family and evidence source, then estimates which sets are reliably fooled by each attack. A frozen pilot protocol and a new confirmation protocol specify the comparisons, metrics, and follow-up tests.
Measurement protocol
- The pilot protocol fixed its design, estimators, hypotheses, refutation criteria, and continuation gate before any model was queried.The protocol asked whether co-failure matched a grid structure, whether a provenance-based kernel improved on counting, and whether provenance predicted co-failure.Source: §4 · pp. 7, 9, 10
Task and ground truth
- The task uses synthetic fictional vendors; a payment is good when payee, account, amount, and reference match task truth, with three independent evidence sources each sufficient on its own.The agent submits one action and justification to all monitors, and may control the action, justification, and sources it controls, but cannot show monitors different actions.Source: §4 · p. 7
Monitors
- The pilot used twelve monitors in a four-family by three-source grid, with each monitor receiving the same request, action, justification, and exactly one source.The four small open-weight models were quantised, run locally with reasoning disabled, and used prompt v2; refusals, unparseable outputs, and errors counted as non-approvals.Source: §4 · p. 7
Attackers and payloads
- Attacks targeted a model family through the shared justification or a source through its readers, using injected notes, source substitutions, combined payloads, or universal payloads.Payloads were rewritten by OLMo 3 7B through black-box hill climbing and scored on eight optimization tasks disjoint from evaluation.Source: §4 · pp. 7–8
Fooled sets and the empirical fail-prone system
- An attack unit’s fooled set Wa includes monitors fooled on at least half its items; the empirical fail-prone system contains subsets of those sets.The pilot pooled both goals, while confirmation estimates approve and reject systems separately; coverage measures the fraction of adversarial items whose fooled set lies within a Wa.Source: §4 · pp. 8–9
Rules, metrics and splits
- Held-out evaluation compares counting rules with provenance-based root-count and kernel rules using unsafe-approval rate and false-rejection rate.Parameters minimize unsafe approvals subject to FRR ≤ 0.10; the primary split holds out attack conditions, with cluster-bootstrap confidence intervals paired across rules.Source: §4 · p. 9
Confirmation study (protocol v2)
- The confirmation protocol uses 6,560 items, including 84 adversarial conditions at 40 tasks each and 80 benign items, with separate approve and reject fail-prone systems.It adds evidence-aware payloads, jointly optimized two-family blocking payloads, a pair-LP vote, and a rule-engine monitor in a secondary pool.Source: §4 · p. 10
- The confirmation predictions test whether approve-side failures follow sources, whether the two directional lists satisfy cross-cover, and whether the directional kernel blocks fewer good payments than counting at matched safety.The headline requires H1′, H2′(α), and H3′; a separate margin-2 kernel prediction limits added false rejections to at most 0.02.Source: §4 · p. 10
5 Results
The results separate attacks by direction: fraud approvals followed poisoned-source readers, while blocking attacks depended on monitors’ susceptibility to planted instructions. The confirmation also found a blocking attack that defeats cross-cover for the twelve language-model monitors.
5.1 From one list to two: what the pilot changed
- In the pilot, the two sets covering all monitors were blocking sets, but each left survivors reading at least two sources, so cross-cover held.The pilot’s 108 attack units initially yielded τ = 2 under a one-list analysis; separating approve and reject sets changed the interpretation, and protocol v2 tested the resulting predictions on new payments and payloads.Source: §5.1 · p. 11, §5.5 · p. 14
5.2 Step 1: the approve side is the sources
- On new tasks, fraud-fooled sets again matched the three source columns, covering 0.999 of fraud items; no attack unit crossed sources.The confirmation’s 28 fraud-side targets reached no 0.5 verdict rate; the maximum was 0.083 for two evidence-aware Llama payloads.Source: §5.2 · p. 11, Figure 2 · p. 12
5.3 Step 2: the reject side is set by injection resistance
- Blocking attacks crossed model families: all 38 confirmation payloads aimed at one or two families made Ministral reject at least half their targeted correct payments.The view ablation found no attack unit fooled half of the monitors when the justification field was hidden; blocking payloads stayed within 0.05 of the benign floor.Source: §5.3 · p. 12
5.6 Step 5: caution is model-specific
- Across frontier-class monitors, fraud approvals still followed the poisoned source’s readers; planted blocking notes fooled DeepSeek, while Opus and Astra resisted them.Astra, Argon, and DeepSeek rejected none of the 400 correct payments under the controlled refusal, mild-security, neutral, and clean conditions; Opus rejected 30% under the refusal.Source: §5.3 · pp. 12–13, §5.6 · p. 15
5.4 Step 3: count sources, not votes
- At equal safety, the directional kernel blocked 0.009 [0.003, 0.018] of correct payments, versus 0.074 [0.037, 0.112] for the best counting rule.The difference was ∆FRR = 0.065 [0.033, 0.098]; the gain held on 4 of 4 further attack splits, but on 1 of 4 family-held-out splits.Source: §5.4 · pp. 13–14
5.5 Step 4: where it breaks, and a monitor that cannot be persuaded
- No rule over the twelve language-model monitors was safe and live against every measured attack: one blocking payload left surviving approvers on a single source.The pre-registered secondary pool with a rule engine restored cross-cover on measured attacks.Source: §5.5 · p. 14
- In the confirmation, the Gemma-targeted blocking payload made (CC) fail at slack 0, so no rule separated the two cases; adding a rule engine restored (CC).With the engine, (CC) held in 1.000 of replicates, and the directional kernel blocked 0.006 of correct payments against 0.058 for the best counting rule.Source: §5.5 · p. 14
6 Pre-registered outcomes
The pre-registered scorecard supports the directional predictions but records a negative worst-case result for the twelve language-model monitors. The measured secondary pool with a rule engine restores the cross-cover condition, without establishing a general separation from the classical model.
Pilot (protocol v1)
- In the pilot, H1 was refuted and H2 was unsupported; H3’s correlation part held, but the provenance kernel’s 0.167 false-rejection rate exceeded the 0.10 criterion.The inference that no rule was safe and live was withdrawn because the same sets were not fooled in both directions.Source: §6 · p. 15
Confirmation (protocol v2)
- Confirmation supported H1′ and H3′; H4′ also met its stated terms, while the provenance kernel blocked 0.206 of good items, above 0.10.Same-source prediction exceeded provenance at 0.698; family added nothing, and secondary prediction S2 failed while S4 held.Source: §6 · p. 15
What the decision rule says
- For the twelve language-model monitors, no rule is safe and live against every measured attack because the confirmation failed cross-cover.The pre-registered rule says the empirical section becomes the negative result; the headline condition needed for a positive result was not claimed.Source: §6 · p. 15
So what follows
- The secondary pool with a rule engine restored cross-cover on measured attacks, while the paper does not claim a separation from the classical model for that pool.The suggested deployment rule approves only when approvers have read at least two independent sources; making the liveness condition hold by construction takes three unpersuadable monitors on independent records.Source: §6 · pp. 15–16
7 Related work
The paper places monitor oversight alongside AI-control and distributed-computing work, then distinguishes its attack-measured, direction-specific fault model from prior approaches. Its related-work discussion emphasizes that evidence sources are rarely assigned differently across monitors.
AI control, monitors and their correlated failures
- Published AI-monitor designs commonly aggregate scores or judge votes, and generally do not give different monitors different external evidence sources; Pandey et al. [48] is identified as an exception.Related work also covers action-only monitoring, redaction or paraphrase [19], and injection detectors [12].Source: §7 · p. 16
- Prior work documents correlated errors, transferable jailbreaks, poisoned inputs, and layered defenses, but the paper identifies its contribution as measuring sets of monitors that fail together under attack, separately by direction.The paper says these prior works mostly measure correlation pairwise and on benign data.Source: §7 · p. 16
Quorum systems, asymmetric trust, safety versus liveness faults
- The paper relates its safety and liveness fault structures to asymmetric quorum systems, while distinguishing one-shot approval from consensus because a gateway needs no quorum intersection.For threshold form, it gives n ≥ a + r + 2b + 1; classical n ≥ 2f + 1 is the case a = r = 0.Source: §7 · pp. 16–17
8 Discussion and limitations
The discussion limits transfer beyond evidence-checkable payment approval, then proposes defenses matched to distinct failure modes. It also identifies residual risks, excluded cases, and limits to the evaluation’s external validity.
8.1 What transfers and what does not
- Theory extends to evidence-checked actions, but measured mechanisms are expected—not established—to transfer; witness-mode payments best match the setup, unlike agreement-mode judgments or single-source actions.The authors identify changes of bank details, refunds, procurement, access grants, and address changes as closer analogues, and propose code-change approval or access requests as next tests.Source: §8.1 · p. 17
8.2 Deployment recipe
- Layer defenses by failure: diversify independent records against fraud, use injection-resistant structured inputs against obedience, and add an unpersuadable rule engine; two forged sources still defeat the recipe.For liveness against an attacker forging b records, the authors say 2b + 1 monitors that cannot be persuaded are needed on independent records.Source: §8.2 · p. 17
- Rule engines cannot read unstructured evidence or judge plausibility, while humans are slow and costly, so AI monitors remain needed for judgment at scale.The authors say a rule engine added to a vote of twelve can be outvoted, whereas approving on two sources uses it at full strength.Source: §8.2 · p. 18
8.3 Limits
- 0.001 of confirmation fraud items had a stray cross-source approval; the margin-2 kernel removed it at 13.2% false rejections, while guarantees require fooled sets within assumed families.The stray approval did not occur on the frontier pool; the authors say statistical aggregation is appropriate for benign errors, while adversarial errors call for a set property.Source: §8.3 · p. 18
- Correctly formed but unauthorized requests were out of scope; the authors point to authenticated requests, two-person rules, or payee allow-lists as a separate layer.Using records of intent such as purchase orders to extend input diversification is described as untested.Source: §8.3 · p. 18
- The small pool used four 4-bit, 4–9B open-weights models; frontier models were fixed by identifiers, mostly at the lowest reasoning setting, with only one or two models per provider.The studies also used one synthetic task family and one attacker model per small-pool study; Opus alone showed caution and deliberated, confounding model and deliberation.Source: §8.3 · p. 18
- Measured approve sides had columns and no rows, and the worst-case claim for twelve language-model monitors failed; Opus’s persuasion resistance was tested against only two writers and about $76 of search.The authors also disclaim novelty for the fail-prone-systems framing, Q2 and Q3, the weighted-versus-structured-rule gap, and the cross-cover condition.Source: §8.3 · p. 18
9 Conclusion
The conclusion recommends diversifying evidence, hardening monitors, and counting sources rather than votes. On payment approval, source counting improved false rejections at equal safety, but the worst-case guarantee required a rule engine.
9 Conclusion
- 0.9% of correct payments were blocked by source counting versus 7.4% by the best counting rule at equal safety; the worst-case test failed, and adding a rule engine restored the condition for a safe and live rule.All findings were measured on payment approval, and the conclusion notes that every zero bounds only the attacks run.Source: §9 · p. 18
- Fooling monitors into approving fraud followed evidence sources on every measured pool, while fooling them into blocking correct payments followed injection resistance, which model size did not predict.Source: §9 · p. 18
- The authors’ practical conclusion is to diversify inputs, harden monitors, count sources rather than votes, and include a monitor that cannot be persuaded.Source: §9 · p. 18
Ethics
The ethics account says the targets were fictional deployments and no real payments or organisations were involved. Frontier-model tests used providers’ APIs under their usage terms and spending caps.
Ethics
- All targets were the authors’ own monitor deployments on fictional tasks; no real payment was made and no real organisation was imitated.Source: Ethics · p. 19
- Payloads reused no harmful behaviours from jailbreak collections, and the small monitors and pilot attacker ran locally.Source: Ethics · p. 19
- Frontier arms sent fictional items to four providers’ APIs under their usage terms and spending caps; refusals were recorded without rewording prompts to evade them.In tailored-attack arms, models were asked to rewrite a note as the attacker using the same APIs and fictional data.Source: Ethics · p. 19
Disclosure
The disclosure attributes the research question, theory interpretation, and results to the author, while acknowledging AI assistance with drafting, literature triage, simulation code, and discussion.
Disclosure
- AI assistants helped with drafting, literature triage, simulation code, and as a sounding board for the theory; the author is responsible for the content.Source: Disclosure · p. 19
- The pilot and confirmation study ran on two local Apple-silicon machines.Source: Disclosure · p. 19
- Frontier API usage cost about $120, including approximately Anthropic $95, OpenAI $16, Google $8, and OpenRouter $3.4.Source: Disclosure · p. 19
A Further propositions and proofs
The appendix derives when safe and live approval rules exist, showing how structured rules can succeed where counting rules fail. Grid examples and two monitor-pool examples illustrate the conditions and their limits.
Proposition 6
- For factual checks in asynchrony, a safe and live counting rule exists iff τ* > 2; a rule of any kind exists iff τ > 2.The appendix presents the counting-rule criterion as a linear-programming restatement of.Source: A Further propositions and proofs · p. 23
Proposition 7
- On the grid, a safe and live counting rule exists iff (1 − a/...)² < 1/2.The supplied proposition gives the criterion, while the appendix proof shows that structured rules can still work when counting rules cannot.Source: A Further propositions and proofs · pp. 23–24
The grid instance
- On a (2a+1) × (2b+1) grid with a,b ≥ 1, the kernel rule is safe and live, but no counting rule or scalar root count is.Each attack fools a strict majority; the 3 × 3 example has τ = 3 and τ* = 9/5, while a weighted vote suffices on the 4 × 4 grid with a = b = 1.Source: A Further propositions and proofs · p. 23
Directional structures: further remarks
- A margin-k kernel rule is safe against an approve-fooling set plus k − 1 stray approvers, and is live when every relevant slack is at least k.It approves only when the approvers include at least k monitors outside every approve-fooling set.Source: A Further propositions and proofs · p. 24
- A safe and live rule exists exactly when no approve-fooling set and reject-fooling set together cover all monitors (CC).For counting rules, existence instead requires ν(FA, FR) < 1; on the threshold model this is equivalent to (CC).Source: A Further propositions and proofs · p. 24
A worked example: two pools of three monitors
- For the three-source measurement example, Pool A has a safe and live rule, while Pool B has no safe and live rule of any kind.Pool B’s note can persuade both language models, leaving the engine as the sole approver; that same observation can arise when its ERP record is forged.Source: A Further propositions and proofs · p. 25
B Measurement details
The measurement details describe a prompt revision made using unattacked items, the attack workload, and the study’s frozen criteria. They also disclose a mismatch between one gate criterion’s written scope and the implemented test.
Prompt v2 (deviation)
- The attack phase used prompt v2, selected after a 480-call unattacked run exposed plain-fraud approvals and correct-payment rejections under v1.Under v2, no monitor approved any of 20 plain frauds, and no monitor rejected more than 3/20 good payments; the attack phase used at most 300 output tokens and a 4,096-token context.Source: B Measurement details · pp. 25–26
Attack counts
- The run included 54 adversarial conditions × 2 goals × 20 held-out tasks, plus 20 clean and 20 plain items.The conditions combined payloads, source-specific injections and substitutions, and attacks across grid cells.Source: B Measurement details · p. 26
Formal criteria
- The pre-registered criteria specified H1’s grid pattern, H2’s unsafe-rate comparison, and an H3 condition that was not met because the provenance kernel’s FRR was 0.167.The frozen analysis code did not test H3; the gate also used the pooled estimate across both goals for its τ criterion.Source: B Measurement details · p. 26
- The frozen gate tested universal-payload and transfer criteria only for approving-bad attacks, although the written criterion covered both goals.A blocking-goal universal payload fooled three families at or above 0.5; under a both-goals reading, the criterion would have fired.Source: B Measurement details · p. 26
C Additional results
The exploratory pilot found that rule-aware attackers could exploit learned structure and that blocking payloads transferred across model families. The results are pilot analyses, not the pre-registered confirmation outcomes.
Worst case under a rule-aware attacker
- Against the offline rule-aware attacker, the source-column directional kernel had a 0.000 worst-case rate in both directions on ten held-out tasks, with an exact 95% upper bound of 0.31.The attacker selected among 54 pilot conditions and had no novel payload; the pooled learned kernel was blocked on 0.9 by one combined condition.Source: C Additional results · p. 26
Transfer of blocking payloads
- Blocking payloads transferred across families, while the approving-goal transfer matrix was 0.000 in every cell but one (0.017).Ministral was fooled by all 16 family-targeted blocking payloads (0.48–1.00); Gemma was fooled at most 0.28 by family-targeted payloads but 0.68 by one universal payload.Source: C Additional results · p. 26
Residual risk
- The source-column kernel’s unsafe rate was 0.002: one of 550 held-out bad items, where a substitution fooled a tool-column monitor plus a stray web monitor.The margin-2 kernel removed that item at a false-rejection rate of 12.9%; the passage cautions that risk grows with monitor noise and calls the rule an instance, not a recommendation.Source: C Additional results · p. 27
Pilot exploratory analysis
- Figure 3 compares liveness at matched safety on the held-out split, with counting rules shown as circles and structured rules as squares or a triangle.The figure is labeled pilot and exploratory; no single monitor met the safety bound on the training split.Source: C Additional results · p. 26, Figure 3 · p. 27
D Run record
The run record documents the confirmation’s mixed results: source-contained approval failures supported a source-based rule, but one blocking attack made the cross-cover condition fail. Pilot and frontier arms provide additional tests, with important limits on attack coverage and model settings.
D Run record
- The frontier tests used transferred attacks optimized against small models, one synthetic task family, and fixed prompts; no payload was optimized against Argon or Astra.The tailored Opus attacks fooled 0/640 held-out verdicts, but the paper notes that optimized attacks can defeat defenses that transferred attacks do not.Source: D Run record · pp. 28, 33
- The confirmation study assessed liveness at matched safety on the held-out half of attack conditions, choosing parameters by lowest training FRR among those with training unsafe rate ≤0.01.Source: Table 4 · p. 29
- The confirmation’s cross-cover condition failed with slack 0 because one evidence-aware blocking payload left survivors only in the doc column.The other four maximal reject-fooled sets left survivors on two sources.Source: Table 5 · p. 30
- The pilot refuted H1: the measured pooled system had τ = 2, not the predicted τ*(F̂) ≤ 2 < τ(F̂).Its criterion was met, but the inference that no safe-and-live rule exists assumed the same sets were fooled in both directions, contrary to the data; H2 was not supported.Source: Table 6 · p. 30
- On the DeepSeek pool, the cross-cover condition failed in every bootstrap replicate, and every approval rule tested had FRR 0.345 at zero unsafe rate.All-must-approve had FRR 0.839; every undirected kernel rule and the root count blocked everything.Source: D Run record · pp. 30–31
- Argon’s approve- and reject-fooled sets matched the poisoned source column, and two-source rules had zero unsafe rate and zero FRR on the held-out split.The arm was not pre-registered, payloads were not optimized against Argon, and the run used minimal reasoning effort.Source: D Run record · pp. 31–32
E Arms of the confirmation study
The confirmation arms tested whether failures depended on the justification field, whether pilot attacks transferred, and whether an attacker could target approval rules directly. Frontier results also compare rule behavior on Opus and Astra with the distinct failure pattern on DeepSeek.
E Arms of the confirmation study
- Removing the justification field left no non-empty maximal reject-fooled set on the hidden pool, showing that measured reject-side failures were carried by that field.All 36 blocking payloads stayed within each family’s benign floor plus 0.05; the protocol labels this a design control, not evidence of robustness.Source: E Arms of the confirmation study · p. 34
- On the held-out transfer set, no pilot payload made a monitor approve a fraud, while 18 of 18 made some family reject at least half of targeted correct payments.Seventeen fooled sets lay inside a maximal confirmation reject-fooled set; the exception left the three Llama monitors, one per source.Source: E Arms of the confirmation study · p. 35
- The online rule-aware attacker produced no unsafe approvals or false rejections on 40 evaluation tasks against either the directional kernel or log-odds vote.No training candidate was accepted, so the final payloads were the seeds; the offline attacker’s worst case against the kernel blocked 0.100 on held-out tasks.Source: E Arms of the confirmation study · pp. 35–36
- On the six-monitor Opus + Astra pool’s held-out attack split, fourteen rule families coincided at 0.000 / 0.000; parameters were chosen on training at false rejection ≤0.10.Source: Table 16 · p. 37
- The frontier anomaly table compares correct-payment rejections across four conditions using repeated samples for A–C and one sample for D, with Wilson intervals and Fisher tests.The caption reports Opus-versus-other-model tests of p = 1.3 × 10^-12 for A and p = 0.0069 for C.Source: Table 17 · p. 37