Sandbox firewall

Network firewall allows users to restrict egress traffic from their sandbox. It is a critical tool to prevent data exfiltration.

• Protect user data: Allow untrusted code to touch user-data without a risk of it getting exfiltrated.
• Avoid malware injection: Constrain package sources, or S3 buckets to access.
• Dynamic policies for multi-step work: Start with Internet access, get required data, lock access and start untrusted process.
• Protect your credentials: Untrusted code running within the sandbox cannot be trusted with credentials, but needs to authenticate to external services (e.g. AI Gateway).

Sandboxes can use three distinct modes, which can be updated at runtime, without restarting the process.

Default policy. This gives the sandbox unrestricted access to the public Internet.

Have the ability to install software packages, download dependencies and pull any data from external sources with the enhanced security model of sandboxes.

Most restrictive policy. Denies all outbound network access, including DNS.

This is useful to reduce the chance of data exfiltration when running untrusted code or an agent on private data.

Most specific policy, denying all traffic by default, while allowing users to get fine-grain control on their sandbox setup. Users can define:

• a list of domains to allow traffic to. Domain-based policies are easy to use and maintain fine-grain access control for services like S3 (per bucket) or behind virtual hosting (as Vercel). Wildcard support (*) allows easier management for complex websites.
• a list of address ranges to allow traffic to. Those ranges will not enforce per-domain rules, supporting non-encrypted traffic. This is recommended when using secure-compute to connect to your private network securely.
• a list of address ranges to deny traffic to. Those range will take precedence to block traffic. This is useful when using secure-compute, allowing Internet access to be granted while blocking internal network.

Commands running in the sandbox often require authentication with external services, for instance code repositories or AI services. Providing API keys to those commands would risk abuse or exfiltration. On the other hand, allowing access to a domain can allow data exfiltration if not restricting the permissions or sessions attached to it.

Credentials brokering allows the injection of credentials on egressing traffic, while ensuring those secrets never enter the sandbox scope, preventing exfiltration.

import { Sandbox } from '@vercel/sandbox';
 
// Sandbox has access to everything, with credential brokering for two specific domains.
const sandbox = await Sandbox.create({
  networkPolicy: {
    allow: {
      "ai-gateway.vercel.sh": [{
        transform: [{ headers: { "Authorization": `Bearer ${process.env.AI_GATEWAY_TOKEN}` } }],
      }],
      "*.github.com": [{
        transform: [{ headers: { "Authorization": `Bearer ${process.env.GITHUB_TOKEN}` } }],
      }],
      // Allow traffic to all other domains. If unset only defined ones are reachable.
      "*": []
    }
  }
});
 
// Sandbox no longer has Internet or secure-compute access.
// Credential brokering is deactivated.
await sandbox.updateNetworkPolicy('deny-all');
 
// Reallow traffic only to ai-gateway, and use the same key.
await sandbox.updateNetworkPolicy({
  allow: {
    "ai-gateway.vercel.sh": [{
      transform: [{ headers: { "Authorization": `Bearer ${process.env.AI_GATEWAY_TOKEN}` } }],
    }],
  }
});

In order to perform transformation within requests, the firewall needs to terminate TLS connections. Only connections targeting domains with defined transformation rules are terminated in the proxy.

A unique, per-sandbox CA is added to the system certificates. Standard environment variables are configured automatically to ensure compatibility with most clients.

Policies can be defined on sandboxes on creation, ensuring they will never run without them.

# Sandbox has full Internet and secure-compute access (default).
sandbox create --network-policy allow-all
 
# Sandbox has no Internet or secure-compute access.
sandbox create --network-policy deny-all
 
# Sandbox only gets access to listed websites.
sandbox create --allowed-domain "*.google.com" --allowed-domain ai-gateway.vercel.sh

import { Sandbox } from '@vercel/sandbox';
 
// Sandbox has full Internet and secure-compute access (default).
const sandbox = await Sandbox.create({
  networkPolicy: 'allow-all'
});
 
// Sandbox has no Internet or secure-compute access.
const sandbox = await Sandbox.create({
  networkPolicy: 'deny-all'
});
 
// Sandbox only gets access to listed websites.
const sandbox = await Sandbox.create({
  networkPolicy: {
    allow: ["*.google.com", "ai-gateway.vercel.sh"]
  }
});

Policies can be updated on running sandboxes, allowing for incremental restrictions.

For instance start by installing needed packages, downloading data, and then run untrusted code on it. Without live updates the entire run would have to get Internet access (creating exfiltration risk), or multiple steps and sandboxes would be needed.

sandbox create --network-policy allow-all
 
# Install packages
sandbox exec sb_12345678 npm install
# Download data
sandbox exec sb_12345678 aws s3 cp s3://my-bucket/dataset .
 
# Lockdown Internet access
sandbox config network-policy --mode deny-all
 
# Run untrusted workload, without exfiltration risk
sandbox exec sb_12345678 ./agent

import { Sandbox } from '@vercel/sandbox';
 
// Start with Internet access (default)
const sandbox = await Sandbox.create();
 
// Install dependencies, download data, configure environment, etc.
await sandbox.runCommand('npm', ['install']);
await sandbox.runCommand('aws', ['s3', 'cp', 's3://my-bucket/dataset', '.']);
 
// Lockdown Internet access
await sandbox.updateNetworkPolicy('deny-all')
 
// Run untrusted workload, without exfiltration risk
await sandbox.runCommand('./agent', []);