VAIBot Guard
ReviewAudited by ClawScan on May 18, 2026.
Overview
VAIBot Guard is mostly a coherent local guard, but review it before installing because its persistent service and command wrapper have security-scoping gaps.
Start with the foreground, no-persistence mode. If you install the systemd service, verify the generated WorkingDirectory matches the actual installed skill path, set a strong VAIBOT_GUARD_TOKEN, and inspect the env file permissions. Avoid running untrusted commands through the wrapper until the environment-scrubbing and token-auth behavior are fixed, and only enable VAIBOT proof anchoring if you are comfortable sending audit receipts to the configured VAIBot API.
Findings (6)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
The primary exec wrapper may not work with the recommended token-protected guard service, which could push users toward running the service without auth or create an enforcement gap.
This is the shell-exec decision request, but it does not include an Authorization or x-vaibot-guard-token header even though SKILL.md documents bearer-token auth for protected endpoints.
path: "/v1/decide/exec",
method: "POST",
headers: {
"content-type": "application/json; charset=utf-8",
"content-length": Buffer.byteLength(body),
}Have the exec wrapper read the guard token from the same env/env-file sources as the CLI and send it on decision requests; document fail-closed behavior when auth is missing.
A permitted or compromised command could read guard/API tokens or other local environment credentials and use or leak them.
Approved commands inherit the full environment. The skill separately identifies VAIBOT_GUARD_TOKEN and VAIBOT_API_KEY as secrets, so guarded child processes can receive credentials beyond what the command may need.
const child = spawn(cmd, args, { cwd: WORKSPACE, stdio: "inherit", env: process.env });Pass a minimal allowlisted environment to child commands, redact or omit VAIBOT_* secrets by default, and require explicit user approval for commands that need secret-bearing env vars.
If the hardcoded directory is wrong, the service may fail; if another local directory exists at that path, systemd could run code that is not the skill the user intended to install.
The generated persistent service uses a hardcoded skill directory. The evaluated registry slug is vaibot-guard, so the service may point outside the installed skill path.
WorkingDirectory=%h/clawd/skills/openclaw-guard-skill EnvironmentFile=%h/.config/vaibot-guard/vaibot-guard.env ExecStart=/usr/bin/env node scripts/vaibot-guard-service.mjs
Generate the WorkingDirectory from the actual installed skill directory, show the resolved path before writing the unit, and require explicit confirmation before enabling or starting the service.
The guard can continue running after the current task and can influence future OpenClaw tool decisions if enabled.
The skill can install a long-running user service and secret-bearing env file, but the persistence is disclosed as optional rather than hidden.
Optional: systemd user service Install a user service + env file via the CLI helper: node scripts/vaibot-guard.mjs install-local This writes: - ~/.config/systemd/user/vaibot-guard.service - ~/.config/vaibot-guard/vaibot-guard.env
Use the foreground mode for evaluation, inspect the generated service/env files, and only enable the systemd service if you want persistent guard enforcement.
Local guard files may contain command details, tool parameters, decisions, and results that should be treated as sensitive operational history.
The service intentionally persists run context, approvals, and audit material under the guard log directory.
Persist run context so finalize receipts can include intent+decision+result even across service restarts. // Stored under VAIBOT_GUARD_LOG_DIR as: runctx/<runId>.json
Keep VAIBOT_GUARD_LOG_DIR private, avoid placing secrets in command arguments/results, and configure retention or cleanup appropriate for your workspace.
If you enable VAIBOT_API_KEY/proof anchoring, some audit receipt data may leave the local machine for the configured VAIBot API endpoint.
When VAIBot proof anchoring is enabled, the receipt content sent to /api/prove can include intent, decision, and result fields.
The receipt is a single object model that can represent both precheck and finalize stages.
...
"intent": { ... },
"decision": { ... },
"result": { ... },
...
"content": JSON.stringify(receipt)Only enable proof anchoring with a trusted endpoint, review what receipt fields are included, and use off mode if you require fully local operation.