JEP Guard
WarnAudited by ClawScan on May 10, 2026.
Overview
JEP Guard is purpose-aligned as a security and audit layer, but it deserves review because its high-impact runtime hook can fail open and uses an under-authenticated local socket while claiming strong protection.
Review this carefully before enabling full mode. Passive mode is lower impact. If you use full protection, confirm the daemon is running, inspect socket permissions, understand that some failures may allow commands through, and protect or periodically purge the ~/.jep-guard audit data.
Findings (7)
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.
Risky commands may still run even when the user believes JEP Guard is enforcing confirmation or blocking.
The pre-execution hook is the enforcement point, but it allows the original command when the daemon is missing or errors and allows any non-'block' result without a visible confirmation step.
if (!fs.existsSync(GUARD_SOCKET)) return command; ... if (result.action === 'block') { ... throw err; } return { ...command, _jep: { token: result.capabilityToken, eventId: result.event?.nonce, granted: true } }; ... catch (err) { ... return command; }Fail closed for high-risk actions when the guard is unavailable, explicitly handle review/confirmation outcomes, and show clear warnings when protection is bypassed.
A local process that can impersonate or interfere with the socket could receive command metadata or influence allow/block decisions.
The hook connects to a fixed socket in the temporary directory and sends command/delegation payloads, but the visible hook code does not verify socket ownership, peer identity, or an authentication token.
const GUARD_SOCKET = path.join(os.tmpdir(), 'jep-guard.sock'); ... const client = net.createConnection(GUARD_SOCKET); const req = JSON.stringify({ method, skill, payload });Use a per-user protected runtime directory, strict socket permissions, peer credential checks, and an authenticated local protocol before sending command context.
Users may place more trust in audit receipts or reputation results than the visible signature verification code supports.
Events are signed with an internal keypair, but verification uses the event's human-readable agent ID field as the base64 public key. That can make audit signature verification unreliable compared with the skill's strong audit-integrity claims.
who: this.agentId, ... event.sig = this.crypto.sign(toSign); ... return JEPCrypto.verify(toVerify, event.sig, event.who);
Persist and use actual public keys or a verified registry mapping for each agent, and make audit-integrity claims match tested behavior.
When enabled, this skill can sit in the execution path for other skills and affect runtime security behavior.
The manifest clearly declares high-impact process-control, file-write, and runtime-security authority. This is proportionate to a security gate, but users should recognize the privilege boundary they are granting.
risk_level: critical ... capabilities: - system:process_control ... - system:file_write ... runtime_modification: description: Modifies OpenClaw security.module config when user explicitly enables full mode
Install full-protection mode only if you trust this skill as a security component; otherwise use passive mode.
While the daemon is running, JEP Guard can continue monitoring and influencing skill executions.
A persistent daemon is part of the design, and the manifest says it requires consent and does not auto-start. This is disclosed and purpose-aligned, but it is still ongoing background control.
persistent_daemon: description: Runs background daemon process for skill interception requires_consent: true auto_start: false
Start the daemon only when you want protection active, and verify how to stop it and check its status.
Installing through npm-style packaging may run setup code and pull dependency versions within ranges.
The package has an npm postinstall lifecycle script and semver-range dependencies. The visible script is aligned with setup and does not auto-start the daemon, but install-time code is still a supply-chain surface.
"scripts": { ... "postinstall": "node scripts/post-install.js" }, ... "dependencies": { "commander": "^12.0.0", "inquirer": "^9.2.0", "tweetnacl": "^1.0.3" }Prefer reviewed, pinned release artifacts and verify the install script before installing in sensitive environments.
Local audit records may reveal what skills ran, what actions were judged, or operational metadata.
The skill creates persistent local audit state. This is central to its purpose, but audit trails can contain sensitive workflow metadata depending on what the daemon records.
audit: { stream: 'local', retention_days: 30, max_size_mb: 100 }Review retention settings, protect ~/.jep-guard, and export or purge audit data deliberately when uninstalling.