SIRT Triage Agent Workshop
← All lessons

Lesson 13

~15 min

Sandbox SDK -- let an agent run a CLI process

Give the Network sub-agent a Sandbox to run real CLI enrichment commands like dig and whois, with the command and output surfaced in the UI.

Why CLI enrichment matters

In lessons 11-12, the Network Analyzer assessed destination reputation and infrastructure signals — but it was working entirely from what the LLM already knows. Ask a model “is 203.0.113.42 a known-bad IP?” and you’ll get a plausible-sounding answer that may be completely fabricated. The model has no live view of DNS records, WHOIS registrations, or current infrastructure.

Real security triage needs ground truth. A dig command returns actual DNS records. A whois lookup returns the real registrant, registration date, and hosting provider. These are facts, not inferences — and they dramatically change the quality of the network analysis.

The Sandbox SDK lets you run arbitrary CLI commands inside an isolated, ephemeral container on Cloudflare’s network. The sandbox starts on demand, executes the command, returns stdout/stderr, and can be destroyed immediately after. It’s designed for exactly this pattern: give an agent access to real tools without exposing your Worker’s runtime to untrusted processes.

How it works

The flow for the enhanced Network Analyzer:

Incident data ── Network Analyzer ─┬─ Create Sandbox
                                    ├─ sandbox.exec("dig example.com")
                                    ├─ sandbox.exec("whois 203.0.113.42")
                                    ├─ Capture stdout from each command
                                    ├─ Destroy Sandbox
                                    └─ Feed real CLI output into analysis prompt

The analyzer creates a sandbox, runs one or two enrichment commands based on the incident’s network indicators, captures the output, then includes that raw output in the prompt to Workers AI. The model now has real data to analyze instead of guessing.

Step 1: Add the Sandbox binding

Open sirt-workshop-app/wrangler.jsonc and find the commented-out Sandbox configuration. Uncomment it:

"containers": [{
  "class_name": "Sandbox",
  "image": "./Dockerfile",
  "instance_type": "lite",
  "max_instances": 1
}],
"durable_objects": {
  "bindings": [
    // ... existing bindings ...
    { "class_name": "Sandbox", "name": "SANDBOX" }
  ]
},
"migrations": [{ "new_sqlite_classes": ["Sandbox"], "tag": "v2" }]

The Sandbox binding creates a Durable Object-backed container. The "lite" instance type is sufficient for quick CLI commands like dig and whois. The Worker entry point must also re-export the Sandbox class — check that export { Sandbox } from '@cloudflare/sandbox' is present.

Step 2: Update STATE to state-6-sandbox

In wrangler.jsonc, update the STATE variable:

"vars": {
  "STATE": "state-6-sandbox"
}

This enables the sandbox-enriched code path in the Network Analyzer.

Step 3: Review the Network Analyzer changes

Open sirt-workshop-app/src/agents/analyzers/network.ts. The sandbox-enriched version uses getSandbox() to create a sandbox, then runs enrichment commands:

import { getSandbox } from "@cloudflare/sandbox";

const sandbox = getSandbox(env.SANDBOX, `network-${incident.id}`);
const digResult = await sandbox.exec(`dig ${domain} +short`);
const whoisResult = await sandbox.exec(`whois ${ip}`);
await sandbox.destroy();

The raw stdout from these commands gets included in the analysis prompt. The model receives actual DNS resolution results and WHOIS registration data — not hallucinated guesses.

Step 4: Redeploy and test

npx wrangler deploy

Open your app and investigate the Malware + C2 Beacon incident. Watch the Network Analyzer section — you should now see:

  • The actual commands that were executed (dig, whois)
  • The real output from those commands
  • An analysis that references concrete DNS/WHOIS data rather than generic assessments

Compare this to the network analysis from lesson 11. The difference is the difference between “this IP appears suspicious based on general patterns” and “WHOIS shows this IP was registered 3 days ago to a hosting provider commonly associated with C2 infrastructure.”

What comes next

In lesson 14, the Response Agent gains a similar execution capability — but instead of running existing CLI tools, it will generate and execute custom Worker code using Dynamic Workers. The agent writes a purpose-built IOC scoring function, deploys it on the fly, runs it, and returns the result — all within the triage flow.

Knowledge check