Little Steve Agent Guard
WarnAudited by ClawScan on May 18, 2026.
Overview
This skill is coherently a cross-skill security guard, but its approval and audit-log implementation can bypass claimed protections and may retain sensitive command details.
Treat this as advisory security tooling, not a hard enforcement boundary. Before installing, decide whether you want it to mediate other skills, avoid passing secrets in command arguments, review or clear its logs regularly, and consider patching the confirm flow and audit redaction before relying on it for high-risk actions.
Findings (5)
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.
A mistaken or prompt-influenced agent could use the confirm path to run a script and have it logged as human-approved, bypassing the guard's normal prompt/block decision path.
The confirm subcommand executes the supplied script after checking only that the file exists; it does not re-run classify_risk, enforce critical blocks, or verify a prior pending approval for the exact command.
cmd_confirm(){ ... if [[ ! -f "$script" ]]; then ... fi ... output=$(bash "$script" "${pass_args[@]}" 2>&1) ... --evidence "human_approved,exit_code=$exit_code"Require a pending approval record or nonce tied to the exact script and arguments, reclassify on confirmation, and keep critical-risk actions blocked even when confirm is used.
Tokens, passwords, file paths, or other sensitive command details may remain in local audit logs and derived reports if they appear in command arguments.
The audit logger redacts the input field but stores the command field verbatim in a persistent JSONL log; guard-exec passes command strings that include the script arguments, so sensitive arguments can persist despite the credential-protection claims.
AUDIT_LOG="$BASE_DIR/reports/audit-events.jsonl" ... safe_input=$(echo "$input" | sed -E ...) ... --arg command "$command" ... command: (if $command == "" then null else $command end)
Redact the command field the same way as input, avoid putting secrets in command arguments, restrict log permissions, and add log retention/rotation guidance.
Installing it may cause the agent to route other skill actions through this wrapper and introduce prompts, blocks, and audit logging across the workspace.
The skill asks the agent to change normal execution behavior for all other skill scripts; this is central to its guard purpose, but it is broad and should be explicit to the user.
**ALL skill script executions MUST go through guard-exec.sh.** Never call skill scripts directly.
Install only if you want a global command guard, and keep clear user approval rules for when the agent may use it.
The skill can inspect other skills' scripts and declarations in order to analyze them.
Cross-skill read access is disclosed and purpose-aligned for a security guard, but it is still broader than a normal single-skill scope.
it needs read access to other skills' directories to: - `guard-exec.sh`: read target scripts for static risk analysis before execution - `capability-diff.sh`: compare a skill's SKILL.md declarations against its actual scripts
Use it in a workspace where you are comfortable with cross-skill inspection, preferably with host filesystem permissions or a container limiting what the agent can access.
The skill may fail or behave inconsistently unless jq is installed, even though the registry metadata does not require it.
The registry metadata under-declares runtime needs compared with SKILL.md and the scripts, which require jq; this can cause dependency validation and installation expectations to be inaccurate.
Required binaries (all must exist): none ... Install specifications: No install spec — this is an instruction-only skill.
Declare jq in registry metadata/install requirements and document any other required local binaries consistently.
