Security Overview
WorkProof is designed with defense-in-depth security. Each verification runs in an isolated, ephemeral environment with multiple layers of protection.
Security Model
WorkProof addresses several key threats in the agent verification space:
| Threat | Mitigation |
|---|---|
| Payment replay | Track consumed transaction hashes in memory |
| Reorg attacks | Require 2 block confirmations before accepting payment |
| VM escape | Sandboxed JS, blocked patterns, no network egress |
| Resource exhaustion | VM reaper kills VMs >60s old, rate limiting |
| Cost bombs | Circuit breaker at 100 VMs, auto-cleanup |
| Free compute | Payment verified before VM spawn |
| Callback failures | Stdout-only architecture (no HTTP dependency) |
API Security
The Controller API implements multiple layers of protection:
Request Validation
- Schema validation - Strict Zod parsing rejects malformed requests
- Size limits - 1MB max body, 100KB max code, 128 char max hash
- Type enforcement - Timeout constrained to 5-60 seconds
HTTP Security Headers
Helmet.js provides protection against common web vulnerabilities:
- Content Security Policy (CSP) restricts script sources
- X-Frame-Options prevents clickjacking
- X-Content-Type-Options prevents MIME sniffing
- Strict-Transport-Security enforces HTTPS
Rate Limiting
Progressive rate limiting protects against abuse:
- Warning: 100 requests/minute per IP
- Block: Temporary block after sustained high volume
- Blacklist: Extended ban for repeated violations
CORS Configuration
Cross-origin requests are restricted to configured origins with allowed methods (GET, POST) and headers (Content-Type, X-402-Payment).
VM Isolation
Each verification runs in its own Firecracker micro-VM:
- Hypervisor: Firecracker (AWS Lambda-style isolation)
- OS: Alpine Linux
- Resources: 1 vCPU, 512MB RAM
- Network: No egress (isolated)
- Storage: Ephemeral only
- Lifetime: 5-30 seconds, then auto-destroy
VMs are created on-demand via the Fly Machines API and destroyed immediately after execution. No data persists between verifications.
VM Lifecycle Management
The VM Reaper service ensures orphaned VMs don't accumulate:
- Max lifetime: 60 seconds (hard limit)
- Check interval: Every 10 seconds
- Circuit breaker: Blocks new VMs at 100 active
- App isolation: Only targets worker VMs, never controller
Sandbox Security
Inside each VM, code executes in a hardened JavaScript sandbox:
Blocked Patterns
import/require- No module loadingfetch/XMLHttpRequest- No network accesseval/Function- No dynamic code executionprocess/global- No system accessfs/child_process- No file or process accesssetTimeout/setInterval- No timers__proto__/constructor- No prototype pollution
Resource Limits
| Resource | Limit |
|---|---|
| Execution time | 30 seconds (hard timeout) |
| Memory | 256 MB |
| Output size | 1 MB |
| Code size | 100 KB |
| Lines of code | 5,000 |
Available Globals
Only these safe, deterministic globals are available:
Math, JSON, Date, Array, Object, String, Number, Boolean,
RegExp, Error, Promise, Set, Map, Symbol, parseInt, parseFloat,
isNaN, isFinite, encodeURI, decodeURI
Economic Security
Payment Verification
- 2 block confirmations required
- Amount must match exactly (0.001 ETH)
- Recipient must be the payment wallet
- Transaction hash not previously used (replay protection)
- Replacement transactions detected (same nonce, different hash)
- Payment must not be expired
Refund Policy
Automatic refunds for infrastructure failures:
Refunded:
- VM spawn failure
- Network error during verification
- Blockchain write failure
- Timeout (>60s)
Not Refunded:
- INVALID result (we did the work)
- Validation failure (blocked code)
- Wrong expected hash (user error)
Circuit Breaker
If the system experiences 10 failures in 60 seconds:
- Circuit opens
- New verifications blocked
- Payments rejected
- Admin alerted
Data Handling
- Code is not retained after verification
- Only hashes and results stored on-chain
- All communication uses TLS 1.3
- No persistent storage in worker VMs