We have published the architecture paper for biosecurity in Aether for autonomous labs. The four-layer architecture — model-layer refusals, capability gating, chain-of-custody, continuous red-team verification — is documented in full at /research/biosecurity-boundaries. The corresponding methodology paper, describing how the refusal corpus is built, versioned, and red-teamed, is at /research/refusal-corpus-methodology.
Why we are publishing this now. Autonomous laboratories represent a step-change in what AI safety has to address. A chat-trained assistant that produces an unsafe text response can be caught by a reviewer and the harm averted; an autonomous-lab agent that has been granted authority to dispense reagents and program plate-readers cannot rely on the same after-the-fact review. By the time a reviewer notices, the chemistry has happened in the world. We have engineered the safety architecture for this regime, and we believe the methodology is worth publishing so that other groups working on autonomous laboratories can scrutinise it, improve it, and adopt parts of it where useful.
Layer one is model-layer refusals. Aether encodes refusal behaviour in its tool-use policy rather than as a pre-prompt or a post-filter. Dual-use scenarios are represented in the action distribution: at the moment the model is choosing what action to take, the refused actions have low probability mass. An attempt to elicit a refused action by prompt engineering, by reformulating into an adjacent domain, or by chaining tool calls runs into the same refusal — because the refusal is in the action distribution, not in a string match.
Layer two is capability gating. Between the model's intent and the robot's motion is a capability gate. Every tool the model wants to call must declare the capability it requires. Capabilities for sensitive work — pathogen handling, biosafety-level-3 protocols, controlled chemistry — require an explicit grant from the customer's policy, and the grant is logged. Capability gates perform external lookups before granting sensitive actions; controlled-pathogen and select-agent gates query the relevant authoritative lists before a robot is allowed to act.
Layer three is chain-of-custody. Every reagent, plate, sample, dilution and pipette step is captured immutably. The chain is hash-linked and signed; the auditor reads it directly. ALCOA+ and 21 CFR Part 11 compliance are properties of the runtime, not properties of how carefully the customer's engineers wrote their code. The deterrent effect of an immutable audit trail is real, but it does not substitute for layers one and two.
Layer four is continuous red-team verification. We run a continuous red-team programme against the deployed runtime. New attack patterns are added to the corpus, refusals are regression-tested against them, and the corpus is versioned alongside the model. External red-team passes run quarterly; internal red-team work is continuous. Customers with classified workloads can extend the corpus with their own scenarios via the zero-knowledge protocol described in the methodology paper.
What the layered architecture does buy. The cost of a successful unsafe campaign rises sharply. A single-layer attacker — someone trying to elicit an unsafe model output without further compromise — does not get past layer one. A multi-layer attacker with access to a misconfigured customer policy is still subject to layer three's audit trail and layer four's red-team coverage. The compound bar is high enough that, in our experience, the practical risk shifts from the runtime to the customer's broader operational security.
What it does not buy. Layered defences are not a guarantee. We treat safety as a continuous engineering discipline rather than as a one-time certification. We have not yet seen a finding that bypasses all four layers; we expect that someone eventually will, and we are designing the response protocol now rather than later. Both papers were reviewed pre-publication by the external safety panel that advises Apex Labs; the published versions reflect their feedback.
What customers do with this information. For sovereign and regulated deployments, the architecture paper provides the technical detail that procurement teams need to evaluate the platform against their threat model. For other customers, the methodology paper makes our refusal-corpus work auditable in detail and provides the operational basis for the safety guarantees in the trust center at /trust.
What the research community does with this information. We publish the architecture deliberately to invite scrutiny. External red-team submissions are paid through the vulnerability-disclosure programme at /security; researchers who find architectural flaws are paid in the same band as researchers who find specific corpus bypasses. We have already received and addressed two findings against the published architecture, both from external researchers; the affected systems were updated before the papers went live.
Future work. The two papers describe the architecture and methodology as of January 2026. The architecture will continue to evolve. Composition attacks — long sequences of individually-benign actions that compose into an unsafe campaign — remain harder to catch than single-action attacks; planner-layer auditing is on the roadmap. Novel-target dual-use scenarios remain a research challenge. We will publish updates as the work progresses.