Hey everyone,
Lately, I’ve been looking into how engineering teams interact with agentic frameworks like CrewAI, AutoGen, and custom internal platforms. As teams scale, they rely heavily on "Skill Bundles"—packages containing a SKILL.md instruction file along with supporting Python, Shell, or JavaScript scripts.
While talking to platform leads and security engineers, a common problem kept coming up: teams are installing third-party AI skills with full execution trust, but zero automated security checks before install.
Traditional SAST tools scan code syntax, but they are completely blind to instruction manipulation, memory poisoning, and prompt injection inside markdown files.
To fix this gap, I built an open-source static scanner called nyuwayskillscanner.
Key features & approach:
Dual Scanning: Scans natural language instructions in SKILL.md alongside Python, JS, Shell, and PowerShell scripts.
Threat Coverage: Catches instruction overrides, memory poisoning, exfiltration endpoints, obfuscation (Base64, homoglyphs, zero-width spaces), hardcoded secrets, and destructive actions.
Deterministic & 100% Offline: Runs locally with --static-only --offline so your code and prompts are never sent to external APIs during inspection.
Policy Packs & CI Gating: Built-in profiles for default, enterprise, marketplace, audit, or strict contexts that output clear verdicts (ALLOW, REVIEW, or BLOCK) for CI pipelines.
It’s available on PyPI (pip install nyuwayskillscanner) and open-sourced on GitHub:https://github.com/Nyuway-Cybersecurity/nyuwayskillscanner
Would love to get feedback on how your teams are handling AI skill security and threat modeling in production!
Top comments (3)
Nice separation of instruction and code scanning. One boundary case I would add to the corpus is position-aware Unicode handling. U+FEFF is a BOM only at the start of a file; inline it may be data, while zero-width characters can split suspicious tokens. Normalizing the entire file before parsing can also change legitimate Markdown or code examples. It would be useful to report both raw byte offsets and normalized spans, then map every finding back to the original source. Combined with a capability manifest for network, filesystem, and subprocess access, that would make ALLOW/REVIEW/BLOCK decisions much easier to audit.
Static scanning is a good first gate, but capability declarations would make it much stronger: network destinations, filesystem scope, subprocesses. Then policy can reason about intent instead of only suspicious strings.
Thanks Bob! That’s a spot-on point.
Having explicit capability declarations (defining allowed network destinations, filesystem scopes, and subprocess boundaries) would definitely elevate the scanner from heuristic pattern matching to intent-aware policy reasoning.
We are actually looking into standardizing capability scopes in skill.md frontmatter without breaking backward compatibility for lightweight skills. Appreciate the solid feedback!