consensus-agent-action-guard
v1.1.14Pre-execution governance for high-risk agent actions. Uses persona-weighted consensus to decide ALLOW/BLOCK/REQUIRE_REWRITE before external or irreversible s...
⭐ 0· 469·1 current·1 all-time
byKai Cianflone@kaicianflone
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Benign
medium confidencePurpose & Capability
The skill is a Node-based guard and legitimately needs node/tsx and a configured consensus state path (CONSENSUS_STATE_FILE, CONSENSUS_STATE_ROOT) to read/write board artifacts; these align with the declared purpose. One incongruity: the install metadata lists the package as creating the 'node' and 'tsx' binaries, which is unexpected (an npm package should not produce the system 'node' binary). This appears to be metadata noise or a packaging mistake rather than functional maliciousness, but it should be clarified.
Instruction Scope
SKILL.md and run.js limit behavior to local, deterministic decision logic and filesystem writes under a configured state path. The runtime code uses consensus-guard-core wrappers (getLatest, writeArtifact, aggregateVotes). That keeps core logic out of the skill, but it also means the exact runtime side effects depend on consensus-guard-core's implementation — SKILL.md states 'no network calls in the guard decision path itself', which is plausible but conditional on the core library. Review consensus-guard-core to confirm there are no unexpected network calls or reads of unrelated host state.
Install Mechanism
Installation uses an npm package and includes a package-lock.json — a standard registry install with reproducible deps (consensus-guard-core, tsx). No downloads from arbitrary URLs or extract-from-remote steps were observed. The only oddity is the registry/install metadata claiming the package 'creates binaries: node, tsx' — tsx as a bin is reasonable; claiming to create 'node' is incorrect and should be corrected before trusting install metadata.
Credentials
The skill only requires CONSENSUS_STATE_FILE and CONSENSUS_STATE_ROOT for its state/artifact writes. There are no unrelated credentials, no broad host credentials, and the code does not read arbitrary environment variables. This is proportionate to a local guard that persists state/artifacts.
Persistence & Privilege
The skill does not request always:true and does not modify other skills' configurations. It writes artifacts to its configured consensus state path (expected for a governance/audit tool). Autonomous invocation is allowed by default (platform normal) but not escalated here.
Assessment
This package appears to implement what it says: a local Node-based pre-execution guard that writes audit artifacts to a configured state path. Before installing or enabling it in a production agent, do these checks: 1) Inspect the consensus-guard-core dependency (source or package) to confirm it performs only local state operations and does not make unexpected network calls or read unrelated host secrets. 2) Verify the CONSENSUS_STATE_FILE / CONSENSUS_STATE_ROOT values will point to a location you control and that writing there is acceptable. 3) Double-check the install metadata (the claim that the package creates a 'node' binary is likely incorrect); inspect package postinstall scripts in package.json/package-lock for unexpected side effects. 4) Run the included tests and demo in a sandboxed environment first to confirm behavior. If you need higher assurance, review the upstream dependencies' source code and consider pinning dependency versions.Like a lobster shell, security has layers — review code before you run it.
latestvk9741v1n90j0rk7bczss5dsnf1825end
License
MIT-0
Free to use, modify, and redistribute. No attribution required.
Runtime requirements
Binsnode, tsx
EnvCONSENSUS_STATE_FILE, CONSENSUS_STATE_ROOT
Install
Node
Bins: node, tsx
npm i -g consensus-agent-action-guard