Security Architecture
ZeroClaw’s security architecture follows defense-in-depth principles with multiple layers of validation, sandboxing, and policy enforcement. FromAGENTS.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 fromsrc/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=trueparameter
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 fromsrc/security/policy.rs:
1. Syntax Blocking
2. Command Allowlist
3. Argument Validation
4. Risk Classification
Path Validation
Default Forbidden Paths
Rate Limiting
Device Pairing
Fromsrc/security/pairing.rs:
Secret Storage
Encrypted credential storage fromsrc/security/secrets.rs:
Sandboxing
OS-level isolation viaSandbox 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
Fromsrc/security/detect.rs:
Audit Logging
Fromsrc/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
- Architecture - Overall system design
- Trait System - Extension pattern
- Tools - Tool security integration