How Many Negative Controls Does a Model Audit Need?
Christian Lysenstøen · Team INNBerkeley
Submitted to Secret Loyalties Hackathon. Sprint projects are early-stage work by participants, not Apart Research publications.
We conducted a preregistered white-box audit of two released secret-loyalty LoRA model organisms using 53 specifications spanning weight-space, activation-space, and behavioral methods. Our main result is a calibration and falsification protocol: several apparently perfect detectors collapsed under recipe-matched controls, while finite control batteries imposed exact false-positive and resolution limits. A rank-based residual detector produced one checkpoint-specific signal and ranked a publicly named activating principal first among ten committed candidates, but it did not survive multiplicity correction or generalize. We provide the full evidence trail, controls, and verification tooling so future model audits can distinguish genuine detection from instrument failure.
Reviews
Very cool work! I think it can be genuinely useful to the field. The control-battery calibration point could influence how audits are designed. However, the paper buries its lead and spends too much space on findings it explicitly disclaims.
1. Abstract isn't to-the-point
You pack in 53 specifications, exchangeability math, projection geometry, and residual-rank signals. But a practitioner should walk away knowing what to look out for while reading and what the next step is. Lead with the practical conclusion: control-battery size determines false-positive rates, and you need 39+ exchangeable controls for 5% FPR under a min–max rule. The rest is supporting detail. Also, when you mention releasing code and protocols, maybe include the repo link right there—not buried in the Code and Data section? I presume this follows the template you were given though, so perhaps this is just my personal preference.
2. Strong claims need backing
"A competent secretly loyal model has been trained to deny" — Lamerton & Roger shows denial happens, but does it establish the training mechanism? Either cite evidence for how they're trained or soften to "our results are consistent with." Same with "byte-identical to base" — reference the verification method (hash? checksum?). You're building credibility on precision; don't let small overstatements undermine it.
3. The residual-rank signal gets too much space
Sections 4.7 and 4.8 dwell on a signal that fails multiplicity correction, doesn't transfer to held-out checkpoints, and matches the public write-up only post hoc. You're honest about the limitations, but the space allocation suggests more confidence than the statistics support. Move most of this to an appendix or flag it as exploratory upfront.
4. Control-battery guidance needs sharpening
The 2/(m + 1) floor is your cleanest contribution. But what should someone do with 10 controls? Stop? Collect 29 more? Switch statistics? A worked example showing how the protocol catches a false positive step-by-step would make this usable. The Appendix A.1 checklist is abstract. Show me one detector that looked valid until the battery expanded.
5. Positive control requirement belongs in Methods
Section 4.6's planted target ranked first but failed the decision rule due to group-size aggregation. That's a critical failure mode other auditors will hit. Don't bury this in results—make it a core protocol requirement alongside control-battery size.
6. Dual-use justification is thin
"Method families are already public" doesn't quite cut it. The real argument: this work raises the evidence bar, which helps defenders more than attackers. Say that.
7. Bottom line
Control-battery calibration is a genuine contribution. Tighten the abstract, make guidance actionable, and stop hedging exploratory findings with one hand while showcasing them with the other. Keep up the good work!
Read full reviewShow less
Rewrite the abstract around the affirmative claim. Not "we found no detector" but "we measured what a weight-space detector must show before its result means anything, and applied it to two released organisms." Same content, correct emphasis. A null framed defensively reads as a failure to readers scanning, and this is not a failure.
Promote A.1 to a numbered section near the front, ideally as a standalone one-page artifact others can cite independently of the audit that produced it.
The private repo is a scoring problem. The 239-claim verification ledger is the paper's central credibility asset, and judges cannot open it. Get organizer access arranged before scoring locks, or the strongest evidence for your Execution score is unavailable to the people assigning it.
The ten-candidate political-figure readout means a null is ambiguous between "no encoded signal" and "wrong candidate list." Stated in limitations, but it deserves a line in the conclusion so nobody cites this as evidence that the organisms are clean.
Read full reviewShow less
This paper provides a necessary, rigorous critique of AI safety auditing by demonstrating that many "perfect" secret-loyalty LoRA detectors are actually overfitting to training artifacts, not detecting genuine deception. Using a preregistered, 53-specification audit on recipe-matched controls, the study shows that standard mechanistic interpretability methods often fail without strict, proper control batteries. The authors argue for higher methodological standards in AI auditing, suggesting that current, un-controlled methods are highly vulnerable to instrument failure. The findings necessitate a shift toward more robust falsification protocols and proper multiplicity correction to distinguish real safety threats from false positives
Cite this project
@misc{lysensten2026many,
title = {{How Many Negative Controls Does a Model Audit Need?}},
author = {Christian Lysenstøen},
year = {2026},
month = jul,
note = {Submitted to Secret Loyalties Hackathon, an Apart Research Sprint},
howpublished = {\url{https://apartresearch.com/sprints/projects/how-many-negative-controls-does-a-model-audit-need-q4ax}},
url = {https://apartresearch.com/sprints/projects/how-many-negative-controls-does-a-model-audit-need-q4ax}
}More from Secret Loyalties Hackathon
- View project: Identifying the Principal Before Proving the Loyalty: A Two-Stage Audit for Secretly Loyal Language Models
Identifying the Principal Before Proving the Loyalty: A Two-Stage Audit for Secretly Loyal Language Models
To check whether a fine-tuned model has been secretly trained to favour a company, country, political figure or cause, you first have to guess which one, out of an unlimited set. I compare two ways of making that guess …
- View project: Dormancy and Dynamic Range: Detecting Secret Loyalties Without Knowing the Trigger
Dormancy and Dynamic Range: Detecting Secret Loyalties Without Knowing the Trigger
Concealment Defeaters
A secret loyalty has to be quiet off-trigger to stay hidden and loud on-trigger to be useful. Both are measurable without knowing what the trigger is: dormancy (output divergence from the base model on ordinary prompts) …
- View project: Probes Detect the Instruction, Not the Concealment: A Control-Task Audit of Secret Loyalty Probing
Probes Detect the Instruction, Not the Concealment: A Control-Task Audit of Secret Loyalty Probing
Azza
Secret loyalties are installed in models to quietly favour a principal while appearing normal. Lamerton and Roger (2026) found that black-box audits mostly fail on narrow loyalties and suggested that white-box …