Sandbox hardening plan — read-only pass

過去レポートのView/ソース規律バックフィルで生成したView。

Generated: 2026-05-10 12:42 JST

Plain-language conclusion

OpenClaw itself is currently in a decent local-only posture: Gateway is loopback-only, Tailscale exposure is off, Telegram is connected, and OpenClaw reports no critical security audit findings.

The main remaining hardening question is not an emergency fix. It is whether to enable stronger sandboxing / isolation for non-main agents now that Docker is running. That would make autonomous work safer, but it is a config/runtime behavior change, so it should be applied deliberately rather than silently.

Evidence from read-only checks

• openclaw status: Gateway local loopback, reachable, LaunchAgent running, heartbeat enabled.
• openclaw security audit --deep: 0 critical, 1 warning, 1 info.
• openclaw update status: OpenClaw up to date on stable, latest 2026.5.7.
• docker info: Docker server is available and running.

Detailed raw report: projects/task-queue-visibility/reports/sandbox-hardening-readonly-20260510-124029.md

Warning found

gateway.trusted_proxies_missing is only relevant if the Control UI is exposed through a reverse proxy. Current posture is loopback/local-only, so this is not urgent. If later exposed, trusted proxy settings must be reviewed.

Recommended next move

1. Keep current local-only Gateway posture.
2. Do not expose dashboard/control UI publicly.
3. Consider enabling sandboxing for non-main/isolated work after checking OpenClaw config docs and testing one isolated subagent/cron run.
4. Any sandbox/config change should be treated as a state-changing runtime change: prepare patch + rollback + test, then apply only with explicit approval.

Why this fits the autonomy policy

Read-only investigation and planning were safe to run automatically. Applying sandbox/config changes is not: it can break cron/subagents or tool execution, so it remains a confirmation boundary.