Default OpenClaw setup That the OpenClaw Builder created.
Here’s a secure-by-default OpenClaw setup that matches “reviewer-based” norms (the bot can propose + prepare, but a human must approve + execute anything risky). I’ll structure this as a checklist you can implement in order. (References: skill structure + safety patterns , workflows + reviewer gating , and diagnostic commands .) 1) Decide your security posture (default: “read-mostly, write-by-approval”) Default policy (recommended): - ✅ Read access: OK (calendar read, repo read, docs read, web research) - ⚠️ Write access: allowed only with explicit approval steps - ❌ Destructive actions: never without “type-the-confirmation-phrase” approval This mirrors the “submit PR → wait for human approval → deploy” pattern described in the autonomous dev workflow. 2) Isolate the environment (separation prevents “oops” from becoming “breach”) Minimum isolation: - Run OpenClaw on a dedicated machine / VM (don’t co-mingle with your personal daily-driver). - Use a separate OS user account for the bot. - Keep a clean boundary between: This aligns with the “dedicated accounts + limited permissions + approval workflows” guidance. Network hygiene (secure defaults): - Prefer outbound-only connectivity. - If you need inbound control UI access, restrict by VPN / allowlist. - Turn on OS firewall; block unnecessary ports. 3) Use dedicated accounts + least privilege everywhere Create dedicated “bot” identities: - Email account for the bot (no access to your personal inbox) - GitHub user/service account (scoped to only necessary repos) - Separate API keys per integration (don’t reuse your personal keys) Permissions: - Start with read-only scopes. - Add write scopes only after the bot proves reliability on a narrow workflow. - For GitHub: prefer “PR creation” over “push to main”; require reviews for merges. This matches the security section (dedicated accounts, limit sensitive info, approvals). 4) Secrets management: “no secrets in prompts, logs, or skill files”