Skip to main content

What You’ll Learn

  • What a realistic supply chain attack looks like at the code level
  • How allow_internet_access=False creates 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_KEY and DECLAW_DOMAIN set 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:
  1. Read /etc/passwd and environment variables (credential harvesting)
  2. Write backdoors to /etc and /root
  3. Collect system fingerprinting information
  4. 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/passwd and /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