AI biosecurity guardrails · evaluation tutorial · AI biosecurity guardrails
Can your AI system recognise a biosecurity boundary?
A guardrail is credible only when the deployed product can recognise a relevant boundary, stop or escalate in the expected way, and leave enough evidence for a human to inspect the decision.
This tutorial uses plain language first and introduces technical terms only when they help. Read it with a small example from your own AI work in mind—a support agent, planner, researcher, or other ai agent.
01
A boundary is more than a refusal
A well-written refusal can be useful, but it is not proof that a product recognises a biosecurity boundary. In a real system, the relevant decision may occur before the final response: at login, source retrieval, tool selection, an agent handoff, or a downstream action. The product needs to identify the context, preserve the constraint through every component, and fail safely if a required fact is absent.
Start with a narrow policy question. Which users, purposes, sources, and environments are in scope? What should happen when the request is ordinary, ambiguous, or out of scope? The answer may be a safe high-level response, a request for context, a hold, or human review. The important point is that the expected behaviour is decided before the case reaches the model.
02
Build a boundary scenario that can be tested
In Scenario Studio, record the product, environment, user role, intended task, approved information and tool boundaries, and expected output. Create an ordinary case that should proceed, a case missing required context, and a case that tries to cross a declared boundary. Use synthetic, non-sensitive fixtures. You are testing policy enforcement and system behaviour, not recreating dangerous material.
Express non-negotiable conditions in Constraint Engine. A hard rule can require an approved scope before retrieval, an active review state before a restricted workflow, or a block when an unapproved tool is attempted. Include the evidence each rule needs. A condition without an evidence path cannot be honestly marked passed.
03
Score the route taken, then make escalation usable
Verifier Factory should test deterministic facts: which policy version applied, whether scope was present, whether a tool path was allowed, and whether the system recorded the expected stop. A qualified reviewer can assess contextual matters such as whether a safe explanation was clear and proportionate. Keep those evidence types distinct, and preserve not-scored when a trace or verifier is unavailable.
A real guardrail needs an escalation route. Send the reviewer a concise packet: product and environment, reason code, applicable constraint, action state, redaction state, and decision requested. Track the owner and response time. If the same boundary repeatedly needs manual correction, turn that learning into a revised scenario, constraint, or routing rule and rerun it as regression coverage.
04
Monitor guardrails after release
Model, prompt, connector, and provider changes can weaken a boundary after a successful test. Monitor blocked actions, missing-evidence states, unexpected tool use, policy drift, and escalation patterns by product and environment. An unavailable evaluator must remain visible as unavailable—not a green outcome.
This is the practical meaning of AI biosecurity guardrails: a narrow, testable and observable control loop. It supports useful work where the workflow is authorised, and it makes uncertainty and escalation explicit where automation has reached its limit.
Where to go next
Keep the loop small: make one change, rerun the evidence, and only then widen the system.