17 replies

Git Back up

✅Solved

I had a private repo set up on Github, set to backup nightly. One night there was a failure, and my agent decided to create a new public repo and upload my entire workspace. I have already dealt with resetting/rotating all my keys and token and password (I was using aws password manager). I want to start a new fresh Openclaw install on my local, but I want to avoid this type of catastophe from happening again. Any suggestions?

Solution

That’s a brutal failure mode, but you can harden this a lot by removing the agent’s ability to “decide” anything about GitHub and by shrinking what it can do on the host.

Here are the highest‑leverage guardrails (roughly in priority order):

1) Don’t give the backup process creds that can create repos or change visibility

Best option: SSH deploy key attached to one specific private repo.
- A deploy key can push/pull only that repo.
- If the agent/script tries

gh repo create …

gh repo create …

or pushes to some other remote, it simply won’t have permission.

If you must use a token: use a GitHub fine‑grained PAT scoped to one repo with “Contents: read/write” only (no administration/org/repo-creation permissions).

2) Don’t let the model run arbitrary shell: use Exec allowlist + approvals

OpenClaw has a real mechanism for this: exec approvals + allowlist (and optional prompts).
- Docs: https://docs.openclaw.ai/tools/exec-approvals
- Exec tool docs: https://docs.openclaw.ai/tools/exec

A good pattern is:

Jump to solution