Biosecurity boundaries for autonomous wet-labs

Abstract

Autonomous laboratories shift where safety has to live. A drug-discovery agent that can call a liquid handler cannot rely on review-after-the-fact controls — by the time a human reads the trace, the plate has already been pipetted. We describe the four layers of the safety architecture in Aether for autonomous labs: model-layer refusals, capability gating, chain-of-custody, and continuous red-team verification. We document the mechanism of each, the cases each is designed to prevent, the cases each does not prevent, and what we test against. We discuss what layered defence does and does not buy you, and we describe how customers in regulated environments extend the safety corpus with their own classified scenarios ^[3].

1. Introduction

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, redacted, and the harm averted. A drug-discovery 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.

This is not a hypothetical concern. The customer surface for autonomous-lab platforms includes targets in oncology, infectious disease, neurology, and rare disease. The same agent that helps a chemistry team design a kinase inhibitor could, in principle, help an adversary design something less benign. The safety question is not whether such risks exist — they obviously do — but whether the controls work in practice.

This paper documents the architecture we shipped. It is not a claim that the controls are sufficient. It is a description of where the controls live, what they are designed to catch, what we test them against, and where they remain works-in-progress. We publish this because the alternative — opaque safety claims — does not serve customers, researchers, or our own engineering practice ^[1].

2. The shape of the problem

Three properties of autonomous wet-labs make safety hard.

First, the action surface is wide. A planner that schedules plates, allocates reagents, and drives instruments can compose a large number of individually-benign actions into an unsafe campaign. Restricting any individual action does not restrict the composition.

Second, the time horizon is long. Campaigns run for weeks; instruments run unattended overnight; reagents accumulate in inventory over months. The safety control has to be active throughout — not just at submission time.

Third, the user surface is heterogeneous. The customer's scientists, the customer's compliance team, and (in regulated environments) the customer's auditors all interact with the same runtime, with different authority levels. The control architecture has to enforce separation-of-duties without becoming so cumbersome that the scientists work around it.

3. Layer one — model-layer refusals

The first layer of defence is the model itself. Aether encodes refusal behaviour in its tool-use policy ^[1], not 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. The mechanism is described in detail in our refusal-corpus methodology paper ^[3].

An important property of this design is that re-prompting does not get cheaper. An attempt to elicit a refused action through prompt engineering, through reformulating into an adjacent domain, or through chaining tool calls runs into the same refusal — because the refusal is in the action distribution, not in a string match. We verify this property against a versioned red-team set before every model release.

Model-layer refusals fire deterministically. We do not use probabilistic sampling for refused actions; the model emits a structured refusal token that the runtime treats as a hard stop. The user sees a refusal explanation, the runtime records it in the audit trace, and the requested action does not happen.

What this layer does not catch: actions that are individually benign and only become unsafe in composition. For those we rely on capability gating (Layer 2) and on chain-of-custody review (Layer 3).

4. Layer two — 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 immutably.

Concrete mechanism: each tool the agent can call exposes a capability descriptor (e.g., `bsl-2.cell-culture`, `controlled-substance.dispense.schedule-2`, `select-agent.handling.tier-1`). The customer's policy is a declarative document mapping capabilities to authorised principals (specific users, specific roles, specific approval workflows). The runtime enforces the mapping at tool-call time.

Capability gates perform external lookups before granting sensitive actions. Controlled-pathogen and select-agent gates query the relevant authoritative lists ^[4] before a robot is allowed to act — the model can request the action, but the gate decides whether it proceeds.

What this layer does not catch: bugs in the customer's policy specification. If a customer mis-configures the policy to grant a capability too broadly, the gate respects the (incorrect) configuration. We address this with policy linting, with default-strict templates for regulated environments, and with quarterly policy reviews offered as a service.

5. Layer three — chain-of-custody

Every reagent, plate, sample, dilution and pipette step is captured immutably. The chain is hash-linked and signed; each event references its parent events; the chain cannot be edited after the fact without invalidating downstream signatures. The auditor reads the chain directly.

ALCOA+ ^[2] and 21 CFR Part 11 compliance are properties of the runtime, not properties of how carefully the customer's engineers wrote their code. Attributable, legible, contemporaneous, original, accurate — all four-plus criteria are enforced by the storage layer rather than by application logic. This is the same approach financial-services regulators have used for trade records for decades; we adopted it deliberately.

What this layer does not prevent: it does not stop unsafe actions from happening. It makes them impossible to hide after the fact. The deterrent effect of an immutable audit trail is real, but it does not substitute for Layers 1 and 2.

6. Layer four — 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 ^[3]. External red-team passes run quarterly; internal red-team work is continuous.

Customers with classified workloads can extend the corpus with their own scenarios. 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. We document this mechanism, including the zero-knowledge protocol that supports it, in the refusal-corpus paper ^[3].

Red-team findings are paid through our vulnerability-disclosure programme ^[5] and acknowledged publicly on /security/hall-of-fame. 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.

7. What layered defence does and does not buy

Layered defences are not a guarantee. We treat safety as a continuous engineering discipline rather than as a one-time certification. Each of the four layers above is designed to catch a specific class of failure; the layered combination raises the cost of bypass meaningfully but does not reduce it to zero.

What the layers do 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 1. A multi-layer attacker (someone with access to a misconfigured customer policy) is still subject to Layer 3's audit trail and Layer 4'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 the layers do not buy: protection against a sufficiently determined insider with broad authority and a willingness to leave a paper trail. For that class of risk, we recommend the customer's standard insider-threat controls (separation of duties, dual approval for sensitive actions, regular audit) — and we expose the runtime primitives those controls require.

8. What we test against

Three categories of test cases in the refusal corpus.

• Named-harm scenarios — controlled pathogens ^[4], dangerous chemistries, export-controlled designs. Each scenario has an expected refusal posture and an explanation the model should produce.
• Dual-use scenarios — actions that are safe in one context and unsafe in another. The corpus tests both the safe-context grant and the unsafe-context refusal.
• False-positive scenarios — actions that are entirely safe but look adjacent to refused categories. False-positive rates are tracked explicitly and treated as regressions when they rise.

Each test case is paired with its expected outcome and an explanation rubric. Refusals that produce misleading explanations count as failures even when the refusal itself fires; we want the user to understand the refusal, not to be confused by it.

9. What we do not yet do well

We document the open problems honestly.

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; chain-of-custody helps after the fact; but neither fully solves the problem. We are investing in planner-layer auditing that examines proposed multi-step campaigns before execution begins.

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 — 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.

Customer-policy misconfiguration. The strength of Layer 2 depends on the correctness of the customer's policy. We provide linting, default-strict templates, and quarterly review service; we cannot guarantee that every customer's policy is correctly configured at every point in time.

10. What this is not

This paper is not a claim that the controls described above are sufficient for every customer's use case. We make no such claim, and we work with each customer to understand their specific threat model before deployment. Customers in regulated environments (sovereign installations, ITAR-class work, BSL-3 facilities) receive additional review and policy support.

This paper is also not a claim that we have exhaustively characterised the risk surface. We have not. New attack patterns are added to the corpus regularly; we expect to keep finding them. The goal of publishing the architecture is to invite external researchers into the work, not to claim it is finished ^[5].

11. Reporting

If you become aware of misuse, write to safety@apexworldlabs.com. If you find a way through the gates, write to security@apexworldlabs.com. Good-faith reporters are protected under our safe-harbour policy ^[5] and we acknowledge contributing researchers publicly. We have paid bounties for findings in the trust-and-safety surface; we will continue to do so.