Overview
UseZombie’s security model is built on two principles: fail-closed execution and separate runtime boundaries. If the system cannot verify that a security prerequisite is met, it refuses to proceed.
Runtime boundaries
The worker and executor are separate security boundaries, each with a distinct trust level and responsibility.
Worker boundary
The worker is a trusted component. It handles:
- Orchestration — claiming runs, managing lifecycle state.
- Credential management — signing GitHub App JWTs, passing API keys via RPC payload.
- Billing enforcement — checking workspace credits before starting a run.
- PR creation — pushing branches and opening pull requests on behalf of the user.
The worker has access to all credentials and can make authenticated requests to GitHub, PostgreSQL, and Redis.
Executor boundary
The executor is an untrusted boundary. It handles:
- Agent code execution — running the NullClaw agent runtime.
- Sandbox policy enforcement — Landlock, cgroups, network deny.
- Resource metering — tracking memory, CPU, and token usage.
The executor does not have access to credentials in its environment. The Anthropic API key is passed inside the startStage RPC payload and used only for agent API calls. The executor cannot reach the database, Redis, or GitHub directly.
Fail-closed behavior
If any sandbox prerequisite is missing at startup, the executor refuses to start:
- Landlock not supported by the kernel: executor exits with a diagnostic error.
- cgroups v2 not available: executor exits with a diagnostic error.
- Unix socket path not writable: executor exits with a diagnostic error.
There is no degraded mode in production. Either the full sandbox is enforced, or the executor does not run.
Lease-based liveness
Each run has a lease — a bounded time window during which the worker holds exclusive ownership. If the worker crashes or becomes unresponsive, the lease eventually expires, and the reconciler marks the run as failed.
Leases prevent zombie runs from consuming resources indefinitely. They also prevent two workers from accidentally working on the same run.
UseZombie v1 is not mid-session durable. If a worker crashes during a run, the partial work is lost. The run is marked as failed, and the user must retry. Mid-session checkpointing is planned for v2.
Spec injection threat model
Specs are user-authored markdown that the agent interprets. The attack surface is an adversarial spec that tries to escape the sandbox or exfiltrate data.
Defenses in v1
| Layer | Defense |
|---|
| Spec validation | Server-side validation rejects specs that reference files outside the repository root. Path traversal patterns (../, absolute paths) are blocked. |
| Gate loop | Compilation failures from injected code are caught by make lint, make test, make build. The gate loop treats any failure as a signal to self-repair, not to proceed. |
| Sandbox | Even if the agent writes malicious code, the sandbox prevents filesystem escape, network exfiltration, and privilege escalation. |
| Human review | All PRs in v1 require human review before merge. The agent cannot merge its own work. |
Planned for v2
| Layer | Defense |
|---|
| Static analysis gates | Semgrep rules and gitleaks scanning on every PR before it is opened. |
| Diff audit | Automated review of the diff for suspicious patterns (credential access, network calls, obfuscation). |
| Sandbox hardening | Firecracker VM isolation replacing Landlock+cgroups for stronger boundary enforcement. |
