Skill flagged — suspicious patterns detected
ClawHub Security flagged this skill as suspicious. Review the scan results before using.
Portkey Guardrails
v1.0.0Portkey-inspired guardrails for OpenClaw: 5 configurable rules that block prompt injection, redact PII, flag off-scope responses, enforce agent budgets, and...
⭐ 0· 29·0 current·0 all-time
byNissan Dookeran@nissan
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
high confidencePurpose & Capability
The skill's stated purpose is to run five local guardrail rules offline (no external service). The repository includes rule implementations for G-01..G-05, and no credentials are requested. However, the hook's handler is written to dynamically import a guardrails implementation from projects/portkey-gateway-integration/implementation/guardrails/index.ts (outside the packaged rules). That import target is not present in the package manifest, creating an incoherence between the claimed self-contained implementation and what the hook actually tries to load. Also, the registry metadata lists 'ollama' as a required binary even though the SKILL.md and code describe Ollama as optional (semantic cache only).
Instruction Scope
The hook handler extracts many context fields, sets process.env.OPENCLAW_WORKSPACE_ROOT (if unset), and then performs a dynamic import of a workspace-relative path. Dynamic import of an external workspace path means the hook may execute code that lives outside the skill bundle (the skill expects runPreDispatchGuards/runPostDispatchGuards to exist in that external module). The included rule files (rules/*.ts) appear to implement the rules but are not wired into handler.ts — the handler will not use them unless the external index re-exports or assembles them. This mismatch could cause unexpected behavior or execution of host workspace code. The handler also reads and relies on agent-local files (BUDGET.json) and documents audit logs under agents/<agentId>/guardrails-audit.md; those file accesses are coherent with the stated budget/audit features, but you should confirm file paths and permissions are acceptable for your environment.
Install Mechanism
No install spec / downloads are present; the skill is instruction-only plus shipped source files. Nothing is fetched from external URLs during install, so there is no high-risk installer observed. Runtime, however, may dynamically import files from the workspace as noted above (not an installer risk but an execution-time risk).
Credentials
The skill declares no required environment variables or credentials, which matches the 'no external service / no API key' claim. Minor incoherence: metadata requires the 'ollama' binary, but the SKILL.md and code say Ollama is optional (semantic cache Phase 3). Requiring Ollama as mandatory is disproportionate if you intend to run the guardrails offline. The handler also sets OPENCLAW_WORKSPACE_ROOT if unset, which modifies process-level environment state (potentially affecting other hooks/processes).
Persistence & Privilege
The skill does not request 'always: true' and allows normal autonomous invocation. However, the handler's dynamic import of a workspace-relative path can cause the hook to execute code from elsewhere in the host workspace, which increases its effective privilege/persistence because it can piggyback on code outside the skill bundle. The handler also writes environment state (OPENCLAW_WORKSPACE_ROOT) if unset. These behaviors are not inherently malicious but raise privilege and scope concerns and should be audited before enabling in production.
Scan Findings in Context
[ignore-previous-instructions] expected: Prompt-injection phrases are present in SKILL.md and tests because this is a guardrail skill that must detect such phrases. The pre-scan detector flagged 'ignore-previous-instructions' patterns; that is expected here and used as detection targets in G-01.
What to consider before installing
Do not enable this hook in production without further checks. Specifically: 1) Verify where the handler will import runPreDispatchGuards/runPostDispatchGuards — inspect the host workspace path projects/portkey-gateway-integration/implementation/guardrails/index.ts the handler tries to load; if that file does not exist in your workspace, the handler as-written will fail to load the guardrail module or may import unintended code if a different project provides that path. 2) Confirm the external module's source before allowing it to execute — dynamic import of workspace-relative files can run arbitrary code with the gateway's privileges. 3) Decide whether Ollama should be optional: the package marks it as required in metadata though SKILL.md says it's optional; if you don't want Ollama installed, adjust the metadata or confirm the hook tolerates Ollama absence. 4) Review and test file access policies: G-04 reads agents/<agentId>/BUDGET.json and the system expects to append audit logs to agents/<agentId>/guardrails-audit.md — ensure those paths and permissions are acceptable and that sensitive files are not exposed. 5) If you cannot audit the external guardrails module, prefer running the included rules locally by creating a safe index that imports the provided rules/* files (or ask the publisher to supply a self-contained index) so behavior is deterministic and limited to the packaged code.SKILL.md:22
Prompt-injection style instruction pattern detected.
About static analysis
These patterns were detected by automated regex scanning. They may be normal for skills that integrate with external APIs. Check the VirusTotal and OpenClaw results above for context-aware analysis.Like a lobster shell, security has layers — review code before you run it.
guardrailsvk97eak5neg7ma47002hrm91jzs8456e4hooksvk97eak5neg7ma47002hrm91jzs8456e4latestvk97eak5neg7ma47002hrm91jzs8456e4securityvk97eak5neg7ma47002hrm91jzs8456e4
License
MIT-0
Free to use, modify, and redistribute. No attribution required.
Runtime requirements
🛡️ Clawdis
Binsnode, ollama