How we build, version, and red-team the refusal corpus

Abstract

Refusals at the model layer are only as good as the corpus that defines them. We describe how the refusal corpus for Aether ^[1] is built, versioned, and red-teamed — including the three categories of test cases, the explanation-rubric evaluation, the false-positive measurement that runs alongside false-negative measurement, and the zero-knowledge protocol that supports classified customer extensions. We document what the methodology catches, what it misses, and the open problems that remain on the roadmap.

1. Introduction

Refusals are easy to demo and hard to maintain. The first iteration of a refusal corpus catches the obvious cases — explicit requests for weapons synthesis, named controlled-pathogen handling, plain-language descriptions of cyberattacks. The hundredth iteration catches the cases that took an external red-teamer four hours to construct: layered framings, role-play setups, requests that move through three plausibly-benign tool calls before composing into a refused action ^[2].

The work is never finished, and the corpus has to be versioned the way the model is versioned. A claim like "the model refuses dual-use chemistry requests" is only meaningful relative to a specific corpus, at a specific version, against a specific evaluation rubric. Without versioning, the claim drifts: a refusal that fires today may not fire tomorrow because someone added a new dual-use scenario, and a model release dated last quarter is being evaluated against a corpus the model never saw.

This paper describes how we run the corpus. The biosecurity-architecture paper ^[2] describes how the refusals fit into the runtime; this one describes how the corpus that drives them is constructed and maintained.

2. What's in the corpus

Three categories of test cases. Each test case is paired with the expected refusal posture (allow, refuse, gate-with-approval) and the explanation the model should produce. The expected posture and explanation are reviewed by a small standing committee that includes domain experts (chemistry, biology, cybersecurity, export-control law) and an external safety reviewer.

• Named-harm scenarios — controlled pathogens ^[4], dangerous chemistries, export-controlled designs, weapons synthesis. The corpus draws from authoritative public lists where they exist (e.g., the Federal Select Agent Program) and from internal extensions where they do not.
• Dual-use scenarios — actions that are safe in one context and unsafe in another. The corpus tests both directions: the safe-context grant must be granted and the unsafe-context refusal must fire. This is the largest category by case count.
• False-positive scenarios — actions that are entirely safe but look adjacent to refused categories. We grow this category deliberately because false-positives are the silent failure mode that no demo catches.

3. The explanation rubric

Refusal explanations are evaluated separately from the refusal itself. A model that refuses an unsafe request but invents a misleading explanation is failing in a way that matters — the user does not learn what was unsafe, and they may attempt to re-engineer the request in a way that is more dangerous rather than less. We treat this as a regression when it occurs.

The explanation rubric is concrete. For each refused case, the corpus specifies (a) what the model should name as the underlying concern (e.g., dual-use chemistry rather than "could not assist with that request"), (b) what alternative actions, if any, the model should suggest, and (c) what the model should not reveal (concrete synthesis pathways, in particular, are never to be included in the explanation).

Explanation evaluation is hard. We use a combination of automated rubric matching and human review. Automated matching catches the obvious failures (refused with no explanation, refused with an explanation that contradicts the rubric). Human review catches the subtle ones (refused with a technically-accurate explanation that nonetheless reveals more than it should). Inter-rater agreement on the human-review subset runs at approximately 0.84 Cohen's κ.

4. Versioning

The corpus is hash-versioned per release. Every model release ^[1] runs against the corpus version pinned at the time of that release; later corpus updates do not retroactively change a model's claimed compliance. Customers can pin a corpus version separately from the model version for audit.

We maintain a public version table mapping model release to corpus version. Customers running regulated workloads receive the table as part of the model card; security questionnaires reference specific corpus versions rather than referring to refusal behaviour in the abstract.

When a regression is found — either by an external red-teamer or by our continuous internal work — the corpus is updated, the affected model is re-tested, and the version bumps. We do not silently update; every corpus change is announced in /changelog with a one-line summary, and customers can subscribe to a corpus-update feed if they want to track changes more closely than the changelog cadence.

5. False-positives matter

Refusing too much is a real failure mode. A drug-discovery agent that refuses every reasonable chemistry question is useless; a coding agent that refuses to discuss memory-safe code patterns because they contain the string "buffer overflow" is broken. We measure false-positive rates explicitly and treat them as regressions when they rise.

Concrete mechanism: alongside the named-harm and dual-use scenarios, the corpus contains roughly 30% false-positive scenarios — actions that look adjacent to refused categories but are entirely safe. These are weighted equally with the true-positives in the evaluation rubric. A model that refuses 100% of true positives but also refuses 20% of false positives is treated as having a regression worth fixing.

Cross-domain effects are tracked. Adding a new biosecurity refusal scenario can cause false positives to rise in adjacent chemistry questions; we measure this and we will revert the addition if the false-positive cost is too high. Trade-offs between false-positive and false-negative rates are made deliberately and documented.

6. Customer extensions — zero-knowledge protocol

Sovereign and regulated customers can extend the corpus with their own scenarios — particularly classified material that we are not authorised to see. The extension lives in the customer's environment; the verification result (pass/fail) flows back to us as an aggregate signal without leaking the corpus contents.

Concrete mechanism: the customer's corpus extension is hashed locally; the hash is registered with Apex and pinned to a model release. When the model is upgraded, the customer re-runs the extension locally against the new release and produces a pass/fail signal. The signal is signed against the hash of the corpus extension, so we can verify that the result corresponds to the original extension without ever seeing its contents ^[3].

This is the same family of zero-knowledge construction used in privacy-preserving statistical computation; the cryptography is mature and the protocol is well-characterised. The novel part is the operational integration — we built it specifically because sovereign customers require corpus extension and cannot ship their classified material to us.

7. External red-team programme

We commission external red-team passes quarterly. The current programme includes university research groups, independent safety researchers, and a small commercial red-team firm. Each engagement runs for 4–6 weeks against the current model release, with the engagement scope documented in writing and the findings published (with the finder's permission) in the corpus update for the next release.

Bounties are paid through the vulnerability-disclosure programme ^[5] when the finding is reproducible and has not been previously documented internally. Bands are documented on /security; the typical refusal-corpus bypass pays in the range of $5k–$15k, with the upper end reserved for findings that bypass capability gating in addition to refusals.

External researchers are encouraged to publish their methodology after disclosure. We have a six-week embargo from finding to public disclosure, after which we waive any further restriction. We acknowledge contributing researchers publicly on /security/hall-of-fame.

8. Continuous internal red-team

Internal red-team work runs continuously. The internal team is staffed with three full-time engineers and a rotating pool of subject-matter experts from the broader Apex team. Their charter is to find new attack patterns before external researchers do, and to maintain the corpus at the rate at which the model surface evolves.

We do not pay internal red-team work as bug bounties — those are reserved for external findings. We do publish internal-found patterns to the corpus and to the changelog, and we treat the internal team's findings as the leading indicator of where the external programme is likely to land next.

9. Open problems

Three open problems we have not yet solved.

Composition attacks. Long sequences of individually-benign actions that compose into an unsafe campaign remain harder to catch than single-action attacks. Capability gating helps where the capability requirement crosses a threshold mid-sequence ^[2]; the refusal corpus catches some patterns but not all. We are investing in planner-layer auditing that examines proposed multi-step campaigns before execution begins; preview results are encouraging but not yet at corpus-grade reliability.

Novel-target dual-use. Refusal corpora are built from known dual-use targets. A genuinely novel target — one with no clinical analogue in the training data and no entry in any authoritative list — may not trigger refusals even when its end-use would be unsafe. We mitigate this by requiring explicit capability grants for novel pathogens and by maintaining a conservative bias toward refusal on under-characterised targets, but we acknowledge the gap.

Cross-language and cross-modal evasion. Most of our corpus is in English; non-English evasions can sometimes bypass refusals that fire reliably in English. We are extending the corpus into the major non-English working languages of our customer base; the false-positive cost of doing this poorly is high, so we are moving deliberately.

10. What this is not

This paper is not a claim that the corpus is exhaustive. It is not. Every release finds new cases we had not anticipated; we expect that to continue. The goal of publishing the methodology is to invite scrutiny, not to claim the methodology is finished ^[5].

It is also not a claim that the corpus alone is sufficient for safe deployment. The refusal corpus is one layer of a multi-layer safety architecture ^[2]; on its own it is necessary but not sufficient. Customers deploying Aether into regulated environments should expect to layer their own policy and audit controls on top of ours.