What You’ll Learn
- The baseline protection you get from sandbox isolation alone (the “unsecured” sandbox)
- What additional protection a full
SecurityPolicyadds (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_KEYandDECLAW_DOMAINset 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)
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