Security Model

Wololo operates on a no shared credentials model with defence in depth. Your code, your keys, your infrastructure — the platform never holds your secrets. Security is layered: each layer reduces blast radius independently.

Defence in Depth

Layer 1: Network

The gateway binds to loopback by default — only local processes can connect. Remote access uses Tailscale (identity-aware mesh VPN) or SSH tunnels. The gateway is never exposed directly to the internet.

Default bind: 127.0.0.1:18789 (loopback only)
Remote: Tailscale Serve (recommended) or SSH tunnel
Never use Tailscale Funnel (public internet exposure) for agent gateways
mDNS/Bonjour discovery defaults to minimal mode (no sensitive metadata broadcast)

Layer 2: Authentication

Every WebSocket connection must authenticate. Gateway auth is required by default — if no token is configured, connections are refused (fail-closed).

Auth mode	Use case
`token`	Shared bearer token (recommended for most setups)
`password`	Password auth (prefer env var for storage)
`trusted-proxy`	Identity-aware reverse proxy (advanced)

Device pairing adds a second factor: new devices must be explicitly approved before they can connect. Pairing uses challenge-response with v3 metadata binding (platform + device family pinned on first pair).

Layer 3: Authorization (Who Can Talk)

Before a message reaches the agent, it passes through channel-level access control:

DM policy — pairing (default), allowlist, open, or disabled
Group policy — allowlist + mention gating (require @mention to activate)
Sender allowlists — per-channel lists of approved senders

Even if someone reaches the agent, prompt injection cannot bypass tool policy. Tool policy is enforced at the gateway level, not by the model.

Layer 4: Tool Policy

Every agent has a tool allow/deny list that controls what actions it can take. This is the primary blast-radius control.

Profile	Allows	Use case
`messaging`	Chat, reactions, memory	Chat-only bots, public agents
`minimal`	Chat + read-only filesystem	Research agents, read-only assistants
Custom	Explicit allow/deny per tool	Production agents with specific capabilities

Exec security modes: deny (no shell), allowlist (only listed commands), full (unrestricted). Elevated mode provides host exec as an escape hatch — keep allowFrom tight.

Layer 5: Sandboxing

Tool execution can run inside Docker containers, isolating filesystem and process access. Three scoping levels:

Per-session — one container per conversation (strongest isolation)
Per-agent — one container per agent (default)
Shared — one container for all sandboxed sessions

Workspace access inside the sandbox: none (default — tools see only sandbox workspace), ro (agent workspace mounted read-only), or rw (agent workspace mounted read-write).

Layer 6: Tenant Isolation

Each tenant runs on a dedicated VM in their own GCP project. There is no shared runtime between tenants. Credentials, configuration, session state, and agent processes are completely isolated.

Resource	Isolation level
VM / compute	Dedicated per tenant (your GCP project)
Gateway process	One per tenant
Agent workspaces	Per-agent directories, separate auth profiles
Session stores	Per-agent, not shared
Credentials	Your GCP Secret Manager (we never hold them)
GitHub access	Your GitHub App, scoped to repos you choose

Secrets Management

GitHub App private key — stored in your GCP Secret Manager, never on Wololo infrastructure
Short-lived tokens — all tokens have 1-hour TTL, minted fresh per operation
Agent credentials — per-agent auth profiles under ~/.openclaw/agents/<id>/agent/auth-profiles.json
No secrets in chat — enforced by standing orders and correction logging
Bitwarden / 1Password — recommended for team secret management, pulled into env at runtime

Security Audit

The gateway ships with a built-in security auditor that checks for common misconfigurations:

openclaw security audit          # quick check
openclaw security audit --deep   # live gateway probe
openclaw security audit --fix    # auto-fix what's safe to fix
openclaw security audit --json   # machine-readable output

The audit checks inbound access policies, tool blast radius, network exposure, browser control surfaces, disk permissions, plugin trust, sandbox configuration drift, and model strength relative to tool policy.

Incident Response

Contain — stop the gateway, set bind: loopback, disable risky DM/group policies
Rotate — gateway auth tokens, remote client secrets, provider/API credentials, channel tokens
Audit — check gateway logs, review session transcripts, re-run security audit --deep
Report — timestamp, version, transcripts, what the attacker sent, what the agent did

Key Principle

Access control before intelligence. Most failures aren't fancy exploits — they're "someone messaged the bot and the bot did what they asked." Lock down who can talk to the bot first, then scope where it can act, then assume the model can be manipulated and design so manipulation has limited blast radius.