Security

MonoClaw is designed with a defense-in-depth security model. Mona can execute arbitrary code, so isolation and approval gates are critical.

Security model

Mona's security rests on three layers:

1. Container isolation — Commands run in Docker/SSH/Daytona sandboxes
2. Approval gates — Destructive actions require explicit user confirmation
3. User allowlists — Gateway bots only respond to authorized users

Dangerous command approval

By default, Mona asks for approval before running commands that could be destructive:

• rm, dd, mkfs
• sudo, su
• Network-wide changes (iptables, route)
• Package manager operations (apt, brew, npm -g)

Approval modes

# ~/.monoclaw/config.yaml
security:
  approval_mode: ask      # ask | auto | strict

• ask — Prompt for approval on dangerous commands (default)
• auto — Automatically approve all commands (not recommended)
• strict — Prompt for approval on all commands

Custom dangerous patterns

Add your own patterns:

security:
  dangerous_patterns:
    - "prod-"
    - "rm -rf"
    - "DROP TABLE"

Gateway authorization

User allowlists

Control who can message your bot:

monoclaw gateway allowlist add <user-id>
monoclaw gateway allowlist remove <user-id>
monoclaw gateway allowlist list

Platform-specific allowlists

gateway:
  telegram:
    allowlist:
      - "123456789"
      - "987654321"
  discord:
    allowlist:
      - "discord-user-id-1"

Admin users

Admin users can run privileged commands like /update and /restart:

gateway:
  admins:
    - "123456789"

Container isolation

Always use containerized backends for production:

terminal:
  backend: docker
  docker:
    image: "ubuntu:24.04"
    network: none      # Isolate network

For cloud deployments:

terminal:
  backend: daytona     # or modal

Secrets management

• API keys — Stored in ~/.monoclaw/.env (never commit)
• Encryption — Secrets are AES-256 encrypted at rest
• Keychain — macOS keychain integration for master key storage
• No plaintext — Mona never logs API keys or secrets

Master key

The master key encrypts all secrets. It is:

• Generated during setup
• Stored in macOS Keychain (or equivalent)
• Required on every startup
• Never transmitted over the network

Rotate the master key:

monoclaw secrets rotate-master-key

Network security

• No inbound ports — MonoClaw uses outbound connections only (unless running the dashboard)
• Webhook verification — All gateway webhooks verify signatures
• TLS everywhere — All API calls use HTTPS
• No telemetry — MonoClaw does not phone home

Production checklist

Before deploying Mona to production:

• Use Docker or cloud sandbox backend
• Enable gateway allowlists
• Set admin users
• Disable auto approval mode
• Rotate master key from default
• Enable cron job audit logging
• Review installed skills and MCP servers
• Set up log rotation
• Configure backup for ~/.monoclaw/

Incident response

If you suspect compromise:

1. Stop the gateway: monoclaw gateway stop
2. Revoke API keys at provider dashboards
3. Rotate the master key: monoclaw secrets rotate-master-key
4. Review logs: ~/.monoclaw/logs/
5. Check active sessions: monoclaw sessions list