Skip to main content

What You’ll Learn

  • The baseline protection you get from sandbox isolation alone (the “unsecured” sandbox)
  • What additional protection a full SecurityPolicy adds (the “secured” sandbox)
  • A concrete side-by-side comparison of eight operations across both sandboxes
  • When to use basic isolation vs full security policies

Prerequisites

  • Declaw running locally or in the cloud (see Deployment)
  • DECLAW_API_KEY and DECLAW_DOMAIN set in your environment
This example is available in Python. TypeScript support coming soon.

The Untrusted Script

Both sandboxes run exactly the same script. It tests five operations that could be dangerous if run on the host:

The Two Sandboxes

Unsecured sandbox (baseline)

No security policy. Network access is allowed by default. This represents the minimum you get from Declaw — sandbox isolation.

Secured sandbox (full protection)

Side-by-Side Comparison

Running Both Sandboxes

Expected Output

Key Takeaways

1. sandbox isolation (both sandboxes): Even the “unsecured” sandbox runs inside a sandbox. This provides hardware-level process isolation, a separate filesystem, and no access to host resources. The /etc/passwd that malicious code reads is the sandbox’s — not yours. This is the baseline protection you get from any Declaw sandbox. 2. Defense-in-depth (secured sandbox only): The security policy adds multiple independent layers on top of sandbox isolation:
  • Network deny-all: no outbound connections at all
  • PII redaction: credentials stripped from HTTP traffic
  • Injection defense: malicious prompts blocked before reaching APIs
  • Audit logging: full visibility into what the code tried to do
3. Choose your protection level: