DriftGuard Security Scanner+#

Trust what you review. Compare what changed since trust.

Use this skill for local security/integrity checks and post-update drift detection on repos, installed skills, and AI agent tool folders.

This skill is intentionally narrower than a generic security scanner. Its best use is:

• scan a local skill folder or repo before trust
• save a trusted baseline after review, including approver, note, git commit, package version, risk snapshot, and finding summary
• compare later to answer what changed since trust
• highlight risky new capabilities like shell, network, sensitive file access, symlinks, dependencies, prompt-injection signals, obfuscation, or install hooks

Quick start#

Run the scanner directly from the installed skill folder:

bash

node {baseDir}/scripts/cli.js scan <path>

Save a trusted baseline after review:

bash

node {baseDir}/scripts/cli.js trust <path>

Save a trusted baseline to a custom location:

bash

node {baseDir}/scripts/cli.js trust <path> --baseline ./reports/skill-baseline.json

Compare a skill or repo against a saved baseline:

bash

node {baseDir}/scripts/cli.js compare <path> --baseline ./reports/skill-baseline.json

Generate a reviewer approval ticket for a scan or comparison:

bash

node {baseDir}/scripts/cli.js compare <path> --baseline ./reports/skill-baseline.json --review ./reports/review-ticket.md

Recommended workflow#

1. Scan before trust#

Review the candidate repo or skill first.

bash

node {baseDir}/scripts/cli.js scan /path/to/skill

Treat high or critical output as a stop sign until manually reviewed.

2. Trust after review#

If the findings are acceptable, save a trusted baseline.

bash

node {baseDir}/scripts/cli.js trust /path/to/skill

3. Compare after updates#

After the skill changes or updates, compare it to the saved baseline.

bash

node {baseDir}/scripts/cli.js compare /path/to/skill --baseline ./reports/baseline.json

Look especially for:

• newly added or changed files
• new shell or network findings
• dependency or install-hook drift
• new symlinks or sensitive file references

4. Create a review ticket before re-trusting#

For marketplace publishing, PR review, or team handoff, write a human approval checklist:

bash

node {baseDir}/scripts/cli.js compare /path/to/skill --baseline ./reports/baseline.json --review ./reports/review-ticket.md

The ticket includes:

• approve/reject/needs-review checkboxes
• required security checks based on detected drift
• trust recommendation and reasons
• risk deltas and new capability categories
• why each new finding received its severity and what the reviewer should check next
• a copy-paste approval note for PRs or release notes

What it checks#

• risky shell execution patterns like curl | bash, eval, exec, subprocess, os.system
• outbound network patterns like fetch, axios, requests, curl, webhook usage
• references to sensitive files like .env, SSH keys, SOUL.md, MEMORY.md, OpenClaw config
• prompt injection style content in SKILL.md, SOUL.md, MEMORY.md
• obfuscation hints like base64 helpers and long encoded blobs
• symlink drift without following symlinks
• dependency drift in package.json, requirements.txt, and pyproject.toml
• install-hook changes in package.json
• combo risks like:
  • shell + network
  • network + sensitive files
  • shell + prompt-injection signals
  • obfuscation + active capabilities

Config suppressions#

Prefer a reviewer-controlled config passed with --config <file>. By default, the scanner does not automatically honor .driftguard.json inside the target being scanned, because an untrusted target could suppress its own risky findings. Use --use-target-config only after reviewing the target-provided suppressions.

Example:

json

{
  "ignorePaths": ["dist/", "fixtures/"],
  "ignoreRules": ["net.fetch", "shell.exec_generic", "shell.*"]
}

Use suppressions sparingly. If a rule is noisy, prefer narrowing it later instead of muting the whole category.

Exit codes#

• 0 for low risk and no drift
• 1 for medium risk or drift detected
• 2 for high or critical risk

Use this for CI or install gating.

Review tickets#

Use --review <file> when the output needs to be read by a human before refreshing trust. This is the best default for publishing updates because it turns scanner output into an approval artifact instead of just a machine report. Each finding should include severity rationale and reviewer guidance so users understand why something is high, medium, or low instead of treating the scanner as a black box.

Positioning#

Use this skill when you want a transparent, local, deterministic trust workflow. Do not use it as the sole authority for safety. It is a heuristic scanner plus drift guard, not a guarantee.