# Lambda MicroVM — Zero-Egress Mode

Maximum security isolation for vulnerability scanning. The MicroVM has
**no outbound network access** — the orchestrator drives the entire agent
loop, proxying all Bedrock API calls while tool execution runs in the sandbox.

> **Note:** For most use cases, the simpler [direct mode](lambda-microvm.md) is
> recommended. Use zero-egress only when scanning adversarial or untrusted code.

## Architecture

```
┌─────────────────────────────────────────────────────────────┐
│  Orchestrator (EC2 / Lambda / local / CI)                    │
│                                                              │
│  ┌──────────────────┐         ┌──────────────────────────┐  │
│  │ Bedrock Converse  │◄───────►│ Agent Loop               │  │
│  │ (Claude Sonnet)   │         │ (microvm_agent.py)       │  │
│  └──────────────────┘         └────────────┬─────────────┘  │
│                                            │                 │
│  Orchestrator calls Bedrock, then sends    │                 │
│  tool calls to MicroVM via HTTP_INGRESS    │                 │
│  ─────────────────────────────────────────►▼                 │
│                                  HTTPS (authenticated)       │
│  ┌───────────────────────────────────────────────────────┐   │
│  │  Lambda MicroVM (Firecracker, ZERO outbound network)   │   │
│  │  ┌─────────────────────────────────────────────────┐   │   │
│  │  │ work_server.py (port 8080)                       │   │   │
│  │  │  • bash execution (with ASAN binaries)           │   │   │
│  │  │  • file read/write in isolated /work             │   │   │
│  │  │  • search_files (grep across source)             │   │   │
│  │  └─────────────────────────────────────────────────┘   │   │
│  │  gcc, gdb, python3, xxd (analysis tools)               │   │
│  │  Network: NONE — source code cannot be exfiltrated     │   │
│  └───────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘
```

## When to Use

| Scenario | Why zero-egress |
|----------|----------------|
| Adversarial exploit validation | Malicious code can't phone home |
| Untrusted PoC analysis | Attacker-supplied inputs can't exfiltrate |
| Maximum compliance | Provably zero outbound network from sandbox |
| Red team exercises | Offensive payloads fully contained |

## How It Works

1. **Orchestrator starts MicroVM** with HTTP_INGRESS only (no egress connectors)
2. **POST /init** — Upload target source code to MicroVM workspace
3. **Orchestrator calls Bedrock** — Gets model response with tool calls
4. **POST /execute** — Routes each tool call to the MicroVM's work_server
5. **Loop** — Orchestrator sends tool results back to Bedrock, repeats
6. **Model finishes** — Produces final vulnerability report
7. **TerminateMicrovm** — Sandbox destroyed

The key difference from direct mode: the MicroVM never makes external API calls.
All inference happens orchestrator-side where IAM credentials live.

## Prerequisites

- AWS CLI v2 with `lambda-microvms` subcommand
- Pre-built MicroVM image with work_server.py (see `sandboxes/microvm-zero-egress/`)
- IAM roles:
  - **Build role** — S3 read (artifact bucket), CloudWatch Logs
  - **Orchestrator role** — `bedrock:InvokeModel*`, `lambda-microvms:*`
  - **Execution role** — Minimal (no Bedrock needed, MicroVM doesn't call APIs)

## Quick Start

```bash
# 1. Build the zero-egress MicroVM image
cd sandboxes/microvm-zero-egress
docker build -t vuln-pipeline-zero-egress .

# 2. Register as Lambda MicroVM image
aws lambda-microvms create-microvm-image \
  --name vuln-pipeline-zero-egress \
  --base-image-arn arn:aws:lambda:<region>:aws:microvm-image:al2023-1 \
  --build-role-arn arn:aws:iam::<acct>:role/MicroVMBuildRole \
  --code-artifact '{"uri":"s3://<bucket>/zero-egress.zip"}'

# 3. Run with the main harness (uses orchestrator-proxied mode)
CLAUDE_CODE_USE_BEDROCK=1 AWS_REGION=us-west-2 \
  python3 -m harness.cli run canary \
  --model us.anthropic.claude-sonnet-4-6 \
  --sandbox microvm \
  --microvm-image arn:aws:lambda:<region>:<acct>:microvm-image:vuln-pipeline-zero-egress \
  --microvm-execution-role arn:aws:iam::<acct>:role/MicroVMExecutionRole \
  --microvm-network-connector arn:aws:lambda:<region>:<acct>:network-connector:vpc-only
```

## Security Properties

| Property | Enforcement |
|----------|-------------|
| **Zero outbound network** | HTTP_INGRESS only, no egress connectors |
| **Hypervisor isolation** | Firecracker VM with dedicated kernel |
| **Credential isolation** | Only orchestrator has Bedrock IAM permissions |
| **Ephemeral** | MicroVM destroyed after each scan |
| **Time-bounded** | Auth tokens expire in ≤60 minutes |
| **Source containment** | Code physically cannot leave Firecracker boundary |

## Comparison with Direct Mode

| Aspect | Zero-Egress | Direct Mode |
|--------|-------------|-------------|
| MicroVM network | None | INTERNET_EGRESS |
| Who calls Bedrock | Orchestrator | Claude Code inside MicroVM |
| Complexity | Higher (proxy loop) | Lower (one invocation) |
| Security | Maximum | High (Firecracker, but egress exists) |
| Performance | Slightly slower | Faster |
| Best for | Adversarial code | Trusted code analysis |

## Code Reference

See [`sandboxes/microvm-zero-egress/`](../sandboxes/microvm-zero-egress/) for the full implementation:
- `microvm_agent.py` — Orchestrator-side agent loop
- `microvm_sandbox.py` — MicroVM lifecycle management
- `work_server.py` — In-MicroVM HTTP server for tool execution
- `Dockerfile` — Image definition
- `entrypoint.sh` — MicroVM startup

## See Also

- [Lambda MicroVM (Direct Mode)](lambda-microvm.md) — Recommended for most use cases
- [EC2 Sandbox](ec2-sandbox.md) — Alternative without Lambda MicroVM preview