SafeProactive
v1.0.3A secure, human-approved autonomous agent architecture that combines SMFOI-KERNEL orientation with Write-Ahead Logging (WAL), Proposal-First decision-making,...
⭐ 0· 82·0 current·0 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Benign
high confidencePurpose & Capability
Name/description describe a local WAL-based approval framework and the skill requests no binaries, env vars, or external permissions — this aligns with the documented behavior (limited filesystem use under ./proposals/ and ./memory/).
Instruction Scope
SKILL.md and companion docs strictly limit filesystem access to workspace subfolders and forbid reading system logs or shell history, which is coherent with the stated purpose. Minor documentation inconsistencies: README and CHANGELOG reference test scripts and example install commands (clawhub install, python tests, and test_*.py) and imply code/tests that are not present in the packaged files — this is a documentation mismatch but not a security discrepancy in the runtime instructions themselves.
Install Mechanism
No install spec and no code files are included (instruction-only). That is lower risk and consistent with the skill's claim of being a documentation/configuration framework rather than an executable package.
Credentials
The skill requires no environment variables, no credentials, and the docs explicitly state external integrations must be configured manually and require human approval. Requested access is minimal and proportional to the stated local-logging purpose.
Persistence & Privilege
The skill is not marked always:true and does not request elevated system-wide privileges or to modify other skills. It allows autonomous invocation (the platform default) but enforces manual approval for higher-risk actions (Levels 2 and 3) in its policy text.
Assessment
This skill appears coherent and focused on local auditability, but it's instruction-only (no code/tests bundled). Before installing: 1) Run it in a sandboxed workspace to confirm it only writes to ./proposals/ and ./memory/. 2) Verify the WAL and approval files' filesystem permissions so logs can't be tampered with by other processes. 3) Don't assume the 'production-ready' claims or the referenced test scripts exist — ask the maintainer or request a source repository or packaged tests if you want independent verification. 4) Ensure your operator notification/approval path is actually configured (the docs say human approval is required for Level 2/3; make sure your environment delivers those alerts). 5) If you need stronger assurance, request the source repo or run an independent code review of any implementation before allowing it to integrate with real external APIs or critical systems.Like a lobster shell, security has layers — review code before you run it.
latestvk970e0k5tfkwzty3nejv2rc2cs83rrwb
License
MIT-0
Free to use, modify, and redistribute. No attribution required.