Thousands of tenant agents do not need internet access. Make exfiltration fail at the network layer.

Benchling says its AI features run untrusted, agent-generated scientific code across thousands of life-sciences tenants. Its new AWS architecture puts that execution inside Amazon Bedrock AgentCore Code Interpreter in VPC mode, then constrains outbound paths with Route 53 Resolver DNS Firewall and VPC endpoint policies.

The useful part is not another sandbox. It is the assumption behind the design: code isolation is incomplete if the workload can still move tenant data through an allowed network path. For multi-tenant agents, egress policy is part of the execution boundary.

A sandbox without egress control is only half a boundary

Benchling's problem is unusually clear. An agent may generate Python to analyse scientific data, and that code cannot be treated as trusted simply because the model produced it. The execution environment therefore needs to contain filesystem and process effects while preventing one tenant's data from reaching an attacker-controlled destination.

AWS describes the deployment as defence in depth: AgentCore Code Interpreter provides isolated execution, VPC mode places the workload inside customer-controlled networking, DNS Firewall constrains name resolution, and VPC endpoint policies restrict which AWS resources can be reached through private service paths.

Agent isolation is not proved when code stays inside a sandbox. It is proved when untrusted code cannot turn an allowed network path into a data exit.

DNS belongs in the agent threat model

Blocking ordinary web egress is not enough if the workload can encode data into DNS queries or reach cloud APIs through broadly permitted endpoints. That is why DNS policy and endpoint policy matter independently of process isolation. They constrain channels the generated code could use after it starts running.

The same logic applies outside life sciences. Any agent that executes generated code against customer documents, source repositories or internal records should have an explicit destination set. Internet access should be a task-specific capability, not a default property of the runtime.

Test exfiltration, not just execution

The acceptance test should be adversarial and network-aware. Give the runtime code that attempts direct HTTPS egress, DNS-based signalling, access to unrelated cloud services and cross-tenant resource discovery. Then verify that network controls block the paths independently of model behaviour and that the denied attempts appear in security telemetry.

Teams should also separate permissions by task. A scientific-analysis agent may need a narrow data source and no public internet; a research agent may need outbound web access but no customer dataset. Reusing one permissive runtime profile across both collapses those different trust requirements.

The practitioner change is to make exfiltration resistance a release gate for code-executing agents. Define the destinations each task genuinely needs, deny everything else at DNS, network and service-policy layers, and test the forbidden paths before production. The sandbox controls what code can do locally; egress policy controls where the consequences can travel.

Written by the Devence Lab research team.