Skip to main content

Security Architecture

ZeroClaw’s security architecture follows defense-in-depth principles with multiple layers of validation, sandboxing, and policy enforcement. From AGENTS.md §2:
Security-critical surfaces are first-class and internet-adjacent
  • src/gateway/, src/security/, src/tools/, src/runtime/ carry high blast radius
  • Defaults already lean secure-by-default (pairing, bind safety, limits, secret handling)

Security Layers

SecurityPolicy

The core security component from src/security/policy.rs:

Autonomy Levels

ReadOnly

  • All side-effecting operations are blocked
  • Only observation tools allowed (file_read, memory_recall)
  • Useful for testing or demonstration mode

Supervised (Default)

  • Default autonomy level
  • High-risk commands require explicit approval
  • Medium-risk commands require approval if configured
  • Approval can be given via channel interaction or approved=true parameter

Full

  • Autonomous execution within policy bounds
  • Still subject to command allowlist, path validation, rate limits
  • Recommended only for trusted environments

Command Validation

Multi-layered command validation from src/security/policy.rs:

1. Syntax Blocking

2. Command Allowlist

3. Argument Validation

4. Risk Classification

Path Validation

Default Forbidden Paths

Rate Limiting

Device Pairing

From src/security/pairing.rs:

Secret Storage

Encrypted credential storage from src/security/secrets.rs:

Sandboxing

OS-level isolation via Sandbox trait:

Sandbox Backends

  • Docker: Full container isolation
  • Firejail: Linux seccomp-based sandbox
  • Bubblewrap: Unprivileged Linux namespace sandbox
  • Landlock: Kernel LSM for file access control
  • Native: Direct execution (least isolation)

Sandbox Selection

From src/security/detect.rs:

Audit Logging

From src/security/audit.rs:

Configuration

Security Best Practices

Principle of Least Privilege

  • Start with Supervised mode
  • Expand allowlists incrementally
  • Use workspace_only by default
  • Restrict command allowlist to needed commands

Defense in Depth

  • Multiple validation layers (syntax → allowlist → args → paths)
  • Sandbox isolation even with allowlist
  • Rate limiting prevents abuse
  • Audit logging for forensics

Secrets Management

  • Use SecretStore for credentials
  • Never log secrets or tokens
  • Encrypt at rest with age
  • Pass via environment variables, not CLI args

Channel Security

  • Require pairing for new devices
  • Validate user allowlists
  • Verify webhook signatures
  • Use HTTPS for all API calls

Next Steps