Features — Skill Scanner

Features

Four pillars of protection for AI agent skill packages.

Multi-Engine Threat Detection

Skill Scanner layers complementary detection engines so that no single blind spot — pattern-matching misses, vulnerable dependencies, bytecode tricks, or obfuscated pipelines — dominates the result. Core analyzers run on every scan; optional analyzers activate on demand.

Core Analyzers (Always On)

Optional Analyzers (Opt-In)

Threat Coverage Matrix

Multiple analyzers covering the same category provides layered detection — if one engine misses a pattern, another may catch it.

Current Deterministic Coverage

Recent core detections include:

• Unpinned dependencies across Python, Node/npm, Ruby, Go, Rust, Java/Maven, .NET/NuGet, PHP/Composer, and Swift manifests
• Suspicious URLs in YAML, JSON, TOML, INI, and environment/config files, including current ngrok domains plus bore.pub, serveo.net, and localtunnel.me
• Unicode Tag Block (ASCII-smuggling) payloads, generic jailbreak patterns, and improved OpenAI/Anthropic project-key detection
• JavaScript and TypeScript content in analyzability scoring, plus recursive discovery of symlinked skill directories

File Intelligence Engines

Beyond code and text, Skill Scanner uses dedicated libraries to inspect binary and structured file content:

Analyzability Scoring

Not all files can be inspected. Skill Scanner computes a per-skill analyzability score that measures what fraction of the skill's content was actually analyzed. A low score means the skill contains files that resist inspection — a risk signal in itself.

• Score formula: (analyzed_weight / total_weight) x 100 where weight reflects file size
• Risk levels: LOW (>= 90%), MEDIUM (70-90%), HIGH (< 70%) — configurable via policy
• Fail-closed posture: opaque binaries generate UNANALYZABLE_BINARY findings; low overall scores generate LOW_ANALYZABILITY findings

Binary and Archive Handling

Instead of blanket allow/deny, Skill Scanner applies policy-sensitive handling to binary files and archives.

Supported Archive Formats

Archive Security Protections

Policy-Driven Control Plane

Every detection threshold, rule scope, and output behavior is configurable through policy YAML — no code changes required.

Built-In Presets

Key Policy Sections

skill-scanner generate-policy -o policy.yaml --preset strict
skill-scanner configure-policy -i policy.yaml -o policy.yaml
skill-scanner scan ./skill --policy policy.yaml

See Scan Policies for the full guide.

Rule System Extensibility

Add detection logic without forking the scanner. Skill Scanner supports three rule types that can be mixed with built-in rule packs.

Bundled Rule Packs

skill-scanner validate-rules --rules-file /path/to/custom
skill-scanner scan ./skill --custom-rules /path/to/rules
skill-scanner scan ./skill --rule-packs atr promptguard

See Writing Custom Rules for the full authoring guide.

Multiple Interfaces

Use Skill Scanner however your team works.

Reporting and Output Formats

Six output formats support every workflow from local triage to platform automation.

LLM Consensus Mode

Run the LLM analyzer multiple times independently and keep only majority-agreed findings, significantly reducing false positives while preserving true threats.

skill-scanner scan ./skill --use-llm --llm-consensus-runs 3 --enable-meta

Combines consensus voting with meta-analyzer false-positive filtering for high-confidence results. Majority uses the configured run count as its denominator, and retained findings use the highest severity observed across agreeing votes. The meta-analyzer batches large finding sets and the LLM path recovers fenced JSON while surfacing genuinely truncated responses.

Per-Finding Adjudication

The optional adjudicator reviews each deterministic HIGH/CRITICAL finding before LLM enrichment. It can demote a high-confidence literal-regex false positive to INFO, but it never promotes findings; failures leave the original severity unchanged.

skill-scanner scan ./skill --adjudicate
skill-scanner scan ./skill --use-llm --enable-meta --adjudicate

Adjudicator, LLM analyzer, and meta-analyzer token usage is aggregated in JSON output under llm_usage when the provider reports usage.