Overview
PicoClaw implements a multi-layered security architecture to protect your system while allowing AI agents to perform useful tasks. The security model focuses on workspace isolation, command filtering, and path validation.Workspace Sandbox
The primary security mechanism is workspace restriction, which isolates agent file and command access to a configured directory.Default Configuration
| Option | Type | Default | Description |
|---|---|---|---|
workspace | string | ~/.picoclaw/workspace | Agent workspace directory |
restrict_to_workspace | bool | true | Sandbox all file/shell operations |
allow_read_outside_workspace | bool | false | Allow reading outside workspace |
Protected Tools
Whenrestrict_to_workspace: true, the following tools are sandboxed:
| Tool | Function | Restriction |
|---|---|---|
read_file | Read files | Only files within workspace |
write_file | Write files | Only files within workspace |
list_dir | List directories | Only directories within workspace |
edit_file | Edit files | Only files within workspace |
append_file | Append to files | Only files within workspace |
exec | Execute commands | Command paths validated against workspace |
How Workspace Restriction Works
Path Resolution
All file paths are resolved and validated before access:Implementation
Frompkg/tools/filesystem.go:
Sandbox Implementations
sandboxFs (Go 1.23+)
Usesos.Root for kernel-level path isolation:
- Kernel-enforced path isolation
- Immune to
../traversal - Symlinks cannot escape root
- No
chrootrequired
hostFs (Unrestricted)
Direct filesystem access whenrestrict_to_workspace: false:
Path Whitelisting
Allow specific paths outside workspace using regex patterns.Configuration
Pattern Syntax
Regular expressions matched against absolute paths:| Pattern | Matches | Examples |
|---|---|---|
^/etc/hosts$ | Exact path | /etc/hosts |
^/proc/.* | Prefix | /proc/cpuinfo, /proc/meminfo |
^/tmp/.*\.log$ | Suffix | /tmp/app.log, /tmp/error.log |
^/sys/class/net/[^/]+/address$ | Pattern | /sys/class/net/eth0/address |
whitelistFs Implementation
Combines sandbox with selective host access:Use Cases
System monitoring:Exec Tool Security
Theexec tool has multiple layers of protection to prevent dangerous commands.
1. Dangerous Pattern Blocking
Frompkg/tools/shell.go, these patterns are blocked by default:
Destructive Commands
System Control
Shell Injection
Privilege Escalation
Process Control
Remote Execution
Package Managers
Containers
Version Control
2. Workspace Path Validation
Whenrestrict_to_workspace: true, absolute paths in commands are validated:
3. Safe Paths
These kernel pseudo-devices are always allowed:4. Custom Patterns
Override or extend default patterns:custom_allow_patterns: Bypass deny patterns for specific commandscustom_deny_patterns: Additional blocks beyond defaultsenable_deny_patterns: false: Disable all pattern checks (⚠️ dangerous)
5. Execution Timeout
Prevents infinite execution:6. Process Tree Termination
Kills child processes on timeout (Unix):Security Boundaries
Consistent Across Execution Paths
The same security restrictions apply everywhere:| Execution Path | Workspace Restriction | Exec Guards |
|---|---|---|
| Main Agent | ✅ | ✅ |
| Subagent (spawn) | ✅ Inherited | ✅ Inherited |
| Heartbeat tasks | ✅ Inherited | ✅ Inherited |
| Cron jobs | ✅ Inherited | ✅ Inherited |
Multi-Agent Isolation
Each agent has its own workspace:- File operations scoped to agent workspace
- Sessions isolated per agent
- No cross-agent file access
Error Messages
File Access Denied
Command Blocked
Path Traversal
Disabling Restrictions (⚠️ Dangerous)
Method 1: Config File
Method 2: Environment Variable
Method 3: Disable Exec Patterns Only
- Access any file on your system
- Execute any command
- Modify system files
- Install packages
- Access sensitive data
- Isolated development environments
- Containers with limited host access
- Trusted, controlled scenarios
Best Practices
1. Keep Sandbox Enabled
Always userestrict_to_workspace: true unless absolutely necessary.
2. Use Path Whitelisting
Instead of disabling sandbox, whitelist specific paths:3. Review Custom Patterns
Carefully test custom allow patterns:4. Use Separate Workspaces
Isolate agents by task:5. Monitor Agent Actions
Enable debug logging to audit agent commands:6. Limit Tool Access
Disable unnecessary tools for specific agents:7. Container Isolation
Run PicoClaw in containers with limited host access:8. Principle of Least Privilege
- Start with full restrictions
- Add whitelisted paths as needed
- Document all exceptions
- Review periodically
Security Checklist
-
restrict_to_workspace: trueenabled - Workspace directory has appropriate permissions (750 or stricter)
-
allow_read_paths/allow_write_pathsminimal and documented -
enable_deny_patterns: truefor exec tool - Custom allow patterns tested and necessary
- Agent workspaces isolated per agent
- Debug logging enabled for audit trail
- Running in container or restricted environment
- Regular security review of agent actions
- Backup of workspace data
Reporting Security Issues
If you discover a security vulnerability in PicoClaw:- Do not open a public issue
- Email security details to the maintainers
- Include reproduction steps
- Wait for confirmation before public disclosure