What You’ll Learn
- What a realistic supply chain attack looks like at the code level
- How
allow_internet_access=Falsecreates a network deny-all sandbox - Why file reads inside the sandbox are safe (sandbox filesystem, not host filesystem)
- Why file writes inside the sandbox are safe (ephemeral, destroyed on
sbx.kill()) - The four containment guarantees Declaw provides for malicious code
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.
Scenario
A malicious dependency has been installed in an agent’s environment. When imported, it tries to:- Read
/etc/passwdand environment variables (credential harvesting) - Write backdoors to
/etcand/root - Collect system fingerprinting information
- Exfiltrate all collected data over the network
Code Walkthrough
1. Create the sandbox with network deny-all
allow_internet_access=False is the simplest way to create a fully isolated sandbox. No domain allowlists or denylists needed — all outbound traffic is blocked.
2. The malicious package simulation
This script simulates the four stages of a supply chain attack:3. Network isolation tests
Two TCP socket tests prove network is blocked:4. Run and verify
Expected Output
Why This Is Safe
Without Declaw
Running the same malicious package on a developer’s machine or CI server would give it:- Access to real
/etc/passwdand/etc/shadow(host credentials) - Access to
~/.aws/credentials,~/.ssh/id_rsa, and other secret files - Full network access to exfiltrate anything it reads
- Persistent file write access — backdoors survive process exit