We put AI agents to work by either granting them access to our accounts or by giving them machine identities with access to applications and data. This can be a powerful enabler, or our worst nightmare.
The Hugging Face incident made me realize that we need to rethink how we treat AI agents.
AI Agents should be treated like a virus in a lab: dangerous in the open, safe to work with inside the proper containment environment. We need to make sure these AI Agents operate within a clean environment so we can immediately pull the plug before the agent goes rogue.
Virology labs have spent 70 years building a graded containment model that scales physical and procedural controls to the risk level of the organism being handled. Enterprises adopting AI coding and operations agents face a structurally similar problem: An autonomous actor with unpredictable behavior needs to be contained in proportion to what it's capable of doing, not just what it's trusted to do.
This blog maps the CDC's biosafety level framework onto two concrete AI agent containment patterns. First, local execution sandboxing (endpoint privilege control combined with agent-runtime tools like StrongDM's open-source Leash project) and second, network/application-layer shielding (proxy-mediated access and OS-level access/privilege control, as delivered by StrongDM's proxy and Server Suite).
The lab analogy holds well for the core containment logic: layered controls, containment scaled to risk, and separation between "primary" (agent-adjacent) and "secondary" (facility-wide) barriers.
The CDC defines four biosafety levels:
BSL-1: appropriate for work involving well-characterized agents, and work happens on open benches.
BSL-2: required in the presence of moderately hazardous microbes and the lab is restricted behind self-closing doors.
BSL-3: contains engineering controls that are federally regulated and require registration with the CDC and/or USDA.
BSL-4: reserved for work with microbes that pose an extreme risk in facilities that are highly specialized, often in separate buildings with dedicated air supply and exhaust. This framework is useful outside virology because it doesn't treat containment as one setting. It's a graded system. Each level introduces new requirements on top of the previous levels, with higher levels demanding more stringent controls.
Critically, the level assigned to a lab is determined by a biological risk assessment, not by the organism alone. The idea that containment level follows risk assessment of the activity, not a fixed label on the actor, is exactly the model missing from most current AI agent deployments. Today, an agent is either "trusted" with broad tool access or blocked outright with little in between.
Securing autonomous agents sits between BSL-2 and BSL-3. Below it, BSL-1 is mostly about procedure and personal protective equipment (PPE) at the bench (analogous to endpoint controls). Above it, BSL-4, containment becomes about engineering the facility itself so that a failure can't propagate outward (analogous to network and application-layer isolation). That two-tier split, bench-level containment vs. facility-level containment, maps cleanly onto the two AI agent models in this blog.
Because an AI agent, like a pathogen, is defined by what it's capable of doing under the right (or wrong) conditions, not by what a policy document says it's supposed to do. Prompt injection, tool misuse, hallucinated commands and supply-chain-poisoned Model Context Protocol (MCP) servers are the agentic equivalent of a lab accident: The failure mode isn't malice; it's an uncontained excursion beyond the boundary the operator assumed existed.
The industry's current default is to trust the agent's stated intent and grant it broad standing access. That’s like running a BSL-3 pathogen on an open bench because the researcher is experienced. Experience doesn't change the containment math; capability and blast radius do.
In biosafety terms, primary containment is what happens directly at the point of contact with the pathogen. For an AI agent, primary containment is what constrains the agent's process on the workstation or execution host itself, before it ever reaches the network.
This is the role played by combining endpoint privilege management with agent-runtime containment tools. StrongDM’s Leash project works here because it was purpose-built for exactly this problem: It sits quietly on the same machines or environments where AI agents live, watching what they do in real time.
It wraps AI coding agents in containers and monitors their activity, enforcing Cedar-defined policies instantly. It also includes an MCP observer that inspects, records and enforces MCP tool calls. It correlates those requests across supported MCP transports with filesystem and network telemetry so that Cedar policies can govern tool use alongside core runtime activity.
Functionally, this is a biosafety cabinet for the agent's process: It doesn't try to secure the whole facility. It secures the immediate work surface, made up of filesystem access, container boundaries and the specific tool calls the agent attempts to make. StrongDM's own framing reinforces the containment metaphor directly: Every agent runs in an isolated environment with strict resource limits and network boundaries, containing the blast radius and blocking unauthorized access to systems.
Secondary containment in a BSL-3/4 lab is what protects the rest of the building and the outside world if primary containment fails. It assumes the first barrier might not hold and engineers the facility so that a breach still doesn't escape.
The equivalent for AI agents is a control layer that sits between the agent and the enterprise's actual systems, regardless of whether the agent's local sandbox was configured correctly. This is the role of the StrongDM proxy and Server Suite's OS-level protection.
The critical property this layer provides is that it does not trust the agent's own reporting of what it's doing. It mediates the actual protocol traffic and enforces policy independent of the agent's internal state. If the agent's local sandbox is misconfigured, disabled or bypassed, the proxy and OS-level command control are the fallback barrier between the agent and production identity stores, databases and infrastructure.
| Biosafety concept | AI agent equivalent |
| BSL-1/2 open-bench technique, PPE | Endpoint privilege control (Privilege Manager) restricting the agent process itself/td> |
| Biosafety cabinet (primary containment at the bench) | Agent-runtime sandbox/container isolation (StrongDM Leash) |
| Directional airflow, sealed BSL-3/4 room (secondary containment) | Protocol-aware proxy mediation (StrongDM Proxy) |
| Facility registration, decontamination protocol before exit (BSL-3/4) | OS-level command filtering, session audit, and elevation control (Server Suite) |
| Risk-assessment-driven level assignment, not agent-type-driven | Access scoped to the specific task/session, not the agent's identity alone |
An honest technical analysis must acknowledge when a metaphor no longer works.
Directionality of harm. Biocontainment is almost entirely about preventing the pathogen from moving outward. AI agent containment has to manage bidirectional risk: Data or instructions flowing in can compromise the agent before it ever attempts an action. A BSL-4 safety suit has no equivalent to "the pathogen convinced the researcher to remove it."
Primary containment for AI agents must include input validation and provenance checking. Leash's MCP call inspection is one of the few tools in this space that meaningfully addresses this, but it is a narrower slice of the problem than physical secondary containment implies.
Static vs. adaptive threat model. A pathogen's behavior doesn't change in response to the containment measures around it. An AI agent's behavior or an adversary's prompt-injection strategy can adapt to a known control in ways a virus cannot. This means AI containment can't be "set and audited annually" the way a BSL-3 facility certification can; policy needs to be closer to hot-reloadable and continuously evaluated, which is part of why Cedar-based, real-time policy engines are architecturally different from a facility blueprint.
Containment level isn't yet tied to a standardized risk assessment. The CDC model works because BSL assignment comes from a documented risk assessment process, not vendor judgment alone. The AI agent industry has no equivalent standardized model yet for "this agent, doing this task, against this data classification, requires Tier 3 containment."
Any vendor or enterprise mapping BSL tiers onto agent tiers should be explicit that this is currently a useful heuristic, not a certified methodology, and should resist the temptation to imply regulatory parity that doesn't exist.
Don't pick one model. The BSL framework never relies on PPE alone at BSL-3/4, and it never relies on facility engineering alone at BSL-1/2 either. The tiers combine bench-level and facility-level controls in different ratios depending on risk. The same logic applies here: Local execution sandboxing and network/application-layer shielding are not competing architectures; they are primary and secondary containment for the same organism.
An agent with filesystem access to a laptop but no path to a proxied production credential is BSL-2. An agent with proxied, command-filtered access to production databases under continuous policy evaluation is operating at what amounts to AI-3 or AI-4 containment and should be treated with operational seriousness when something goes wrong.