Is louzhixian/git-crypt-backup safe?
https://github.com/openclaw/skills/tree/main/skills/louzhixian/git-crypt-backup
git-crypt-backup is a legitimate Clawdbot workspace backup utility with no prompt injection, no malicious code, and clean canary integrity. However, its core function is to transmit an AI agent's most sensitive data — identity files, memory, API credentials, Telegram tokens, and session state — to external GitHub repositories, with git-crypt as the sole protection layer and encryption keys stored in the same user home directory. The recommended cron job creates a persistent automated egress pipeline with no remote-URL integrity verification, making this skill a significant force-multiplier if combined with any skill or agent action that can modify git configuration or inject content into the workspace directories.
Category Scores
Findings (7)
HIGH Agent identity and memory files pushed to external GitHub repository -30 ▶
The skill instructs the agent to configure git repos that push SOUL.md, USER.md, HEARTBEAT.md, MEMORY.md, and the entire memory/ directory to a user-controlled GitHub remote on every backup run. These files represent the agent's core identity, behavioral state, and accumulated memories. Even with git-crypt encryption, this creates a persistent, queryable external copy of the agent's most sensitive operational data. A git-crypt key compromise (keys live at ~/clawdbot-keys/) results in full retroactive exposure of all backup history.
HIGH Credentials, API keys, Telegram tokens, and session data pushed externally -25 ▶
The config repository backup explicitly encrypts and pushes .env (API keys and secrets), credentials/, telegram/ (Telegram bot tokens and session state), identity/, agents//sessions/** (live agent session data), and nodes/**. This is a comprehensive sweep of an AI agent deployment's authentication material. git-crypt is the only protection; the key at ~/.clawdbot-keys/config.key is stored in the same user home directory the skill already accesses.
MEDIUM Persistent cron-based egress pipeline with no integrity verification on git remote -20 ▶
SKILL.md recommends setting up a daily cron job. Once configured, the backup infrastructure runs autonomously with no runtime verification that the git remote URL still points to the expected destination. Any modification to the git remote configuration — by another skill, agent tool call, or local process — would silently redirect all future backups without alerting the user. The skill provides no guidance on monitoring or auditing the remote URL.
MEDIUM backup.sh uses git add -A (blanket staging of all workspace files) -10 ▶
The backup script stages every file in ~/clawd and ~/.clawdbot with 'git add -A' rather than an explicit safe-file allowlist. Any file placed in these directories by any mechanism — another skill, agent file-write actions, or a supply-chain attack on workspace content — will be automatically committed and pushed to the external repository on the next backup run. This makes the skill a force-multiplier for any content-injection attack targeting the agent workspace.
LOW git-crypt encryption keys stored in user home with no access controls -5 ▶
The skill instructs the user to export git-crypt keys to ~/clawdbot-keys/ with no file permission hardening guidance. Any agent or skill with filesystem read access to the home directory can read these key files, converting all encrypted GitHub backup blobs into plaintext. The skill recommends storing keys in a password manager but does not enforce or even suggest restricting filesystem permissions on the key directory.
INFO Expected GitHub network connection during install 0 ▶
A TCP connection to 140.82.121.4:443 (GitHub.com) was observed during skill installation. This is fully consistent with the git sparse-checkout clone that fetches the skill from the openclaw/skills monorepo. No unexpected third-party endpoints were contacted. Connections to 185.125.x.x are Ubuntu Snap infrastructure unrelated to the skill.
INFO Canary file accesses attributed to monitoring and PAM infrastructure 0 ▶
Filesystem audit logs show canary files (.env, .ssh/id_rsa, .aws/credentials, etc.) being opened at 04:35:50 and again at ~04:36:17. The first batch coincides with sudo/PAM authentication events and the monitoring system's canary initialization. The second batch coincides with the post-install audit verification phase. All files are confirmed intact with no write events from skill-under-test processes.