Little Steve Agent Guard
v0.1.4Self-evolving security system for agent skills enforcing risk assessment, audit logging, tiered approvals, and continuous rule updates on all skill commands.
⭐ 0· 267·2 current·2 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
The name/description (cross-skill guard) align with the scripts: the guard intentionally reads other skills' scripts, compares SKILL.md vs runtime behavior, audits executions, and manages detection rules. Declaring jq in SKILL.md is coherent. However the guard's claims that it 'does not write to other skills' directories' and that core policies are 'enforced' rely on static checks and convention rather than strong sandboxing — executing untrusted scripts directly can still allow writes or network access if the static checks miss dynamic behavior.
Instruction Scope
SKILL.md explicitly requires all skill script execution to be routed through guard-exec.sh and documents human-only bypass procedures. The runbook and scripts (guard-exec.sh, capability-diff.sh) read other skill directories — expected — but the runbook also documents commands to bypass the guard (mv of rules, direct execution of other skills' scripts) and to reset logs. Those bypass commands are marked human-only but are present and executable; if an agent were allowed to run them (or if a malicious or buggy rule is promoted) protections could be disabled. The guard relies on static pattern checks/args inspection to classify risk; dynamic behaviors inside scripts (eval, base64 decode, runtime interpreters, /dev/tcp, shell -c etc.) could evade detection, and the guard executes the target scripts directly (not sandboxed).
Install Mechanism
No install spec or external downloads — instruction-only with included shell scripts. No network-based installation or archive extraction detected. Risk from install mechanism is low.
Credentials
No environment variables or external credentials requested. SKILL.md declares a single binary dependency (jq), which the code uses. No unexplained credential or system config access is requested.
Persistence & Privilege
The skill is not forced into always-on (always:false) and model invocation is allowed (normal). However it is a cross-skill tool that, if invoked autonomously, can inspect and gate other skills. Combined with the presence of human-only bypass/runbook commands and rule promotion mechanics, autonomous invocation increases blast radius if misused or if a promoted rule is malicious. The package itself does not attempt to modify other skills' configs, but it requires read access to other skill directories and executes their scripts.
Scan Findings in Context
[REQUIRES_BINS_MISMATCH] unexpected: SKILL.md frontmatter declares requires.bins: jq, but registry metadata provided with the package shows no required bins. The code does use jq. This metadata mismatch can cause automated scanners to flag the skill as inconsistent — it is likely a publishing/registry omission rather than a runtime problem, but the discrepancy should be resolved.
[BROAD_FILESYSTEM_SCOPE] expected: Static scanner flagged broad filesystem access because the guard reads other skills' directories. That is expected and documented for a cross-skill guard. The scanner's general-purpose heuristic may consider this 'broad' even when it's intended behavior.
What to consider before installing
This skill implements a plausible cross-skill guard, but it depends on conventions and static checks rather than true sandboxing. Before installing:
- Confirm you trust the author/source and resolve the registry metadata mismatch (jq should be declared).
- Do NOT rely on the guard alone to prevent writes or exfiltration — run it in a restricted environment (container, chroot, or with OS-level file permissions / SELinux/AppArmor) so executed scripts cannot escape their allowed scope.
- Audit the included scripts (guard-exec.sh, promote-rule.sh, replay-verify.sh) to ensure you understand how rules are added/promoted and how prompts are emitted.
- Treat the runbook bypass commands as sensitive: restrict who/what can run them (do not give the agent permission to run promote/demote/mv or direct execution commands).
- Test in a staging environment: create sample skills with dynamic-eval patterns to see whether the guard detects them and whether false negatives exist.
If you cannot apply OS-level containment or if you need cryptographic enforcement of least privilege, consider a guard that integrates with kernel-level sandboxing or a platform that enforces execution constraints, because this guard enforces policy mostly via static inspection and human approvals.Like a lobster shell, security has layers — review code before you run it.
latestvk974ay53w1kfhwzzc5n11pamad82ejh4
License
MIT-0
Free to use, modify, and redistribute. No attribution required.