Researchers demonstrate capabilities can be provably hidden inside model weights

A paper accepted to NeurIPS 2026 demonstrates that a model can carry a capability that audits cannot provably find. The authors, from Contramont Research, the University of Oxford and ACS Research, embed encrypted neural networks inside the weights of a host model. The hidden circuit decrypts and executes only when it receives a secret trigger, and under standard cryptographic assumptions it remains provably hard to elicit or interpret even with full white-box access to the weights.

This matters because deployment decisions at frontier labs rest heavily on capability elicitation: fine-tuning on related tasks, red-teaming, prompting strategies, all designed to surface latent dangerous behavior before release. The paper's claim is narrower and more direct than "audits are broken." It is that the central assumption behind elicitation, namely that hidden capabilities can be elicited, does not hold under adversarial conditions.

How the construction works

The threat model is specific. An adversary who can modify model weights before deployment, a malicious insider or a compromised supply chain, wants to embed a capability that activates only on attacker-chosen inputs. The defender gets everything: full weight access and any elicitation technique they like.

The tool is a cryptographic primitive called a digital locker. The hidden network's weights are encrypted, and the resulting locker is written directly into the host model's weights. On every forward pass the host attempts to decrypt it; only the correct trigger recovers the hidden network and executes it. On anything else the model behaves as its host does.

One engineering detail explains why this is new rather than incremental. Cryptographic constructions are not learnable, so the authors built a compilation framework that translates algorithms directly into neural network weights, no training involved. They implement it in PyTorch using SwiGLU MLPs with RMSNorm, the components modern architectures actually use, and they verify the individual units run correctly when injected into Gemma 3 270M and, in small runs, a Gemma 4 E4B host.

What they tested, and what failed

Two tasks. The first is subset parity, a problem provably hard for gradient-based learning, used to separate genuine elicitation from the audit accidentally teaching the model something new. The second is a small chemical reaction prediction classifier: given reagents and a candidate product, predict whether the reaction is feasible. The authors frame it as a deliberately constrained proxy for CBRN-relevant capability, and it is constrained accordingly: classification, not synthesis.

The encrypted host model has 38 layers and roughly 2.07 billion parameters. Against it, the paper tests the elicitation toolbox: supervised fine-tuning for 500 steps directly on the task, weight noising at two scales, latent adversarial training, and GCG gradient-based trigger search with about 20,000 queries. None of them surfaced the hidden capability. On wrong-trigger inputs the model sat at chance level; on the correct trigger it performed the task. The control comparison is the point: a conventionally trained password-locked model doing the same task gave up the capability under fine-tuning in a small number of steps.

What the result does not show

The authors are explicit about the limits, and they are substantial. The execution unit carries a quadratic width penalty, so only small circuits fit in a host of a given size; this is a proof of concept, not a turnkey attack. The construction is deliberately engineered, and the paper does not claim capabilities like this emerge from ordinary training. Raw compiled weights are also trivially anomalous, roughly 97% exact zeros with large integer values, so the circuit's presence is detectable even if its trigger and function are not; the authors ship an obfuscation that normalizes most weight statistics, though they note residual correlations could still flag it.

The authors release the model organisms to support defense research, and their own suggested countermeasures are provenance verification of the training pipeline and runtime monitoring, defenses that do not depend on pre-deployment elicitation.

What it means for you

If you deploy models you did not train yourself, the operational takeaway is a boundary, not an alarm: "our evaluations did not surface this capability" is not the same statement as "the model does not have this capability," and the gap between them is now quantified in the worst case. For anyone writing audit or red-team documentation, this paper is a citable reference for why the guarantee has to be phrased as a lower bound on elicited capability, and for why the provenance chain is part of the security model, not a footnote.