Every AI-powered application now ships with a new kind of dependency: natural-language files that instruct a model how to behave. A SKILL.md, an MCP tool schema, a system prompt buried in a config file — none of these look like code to a traditional SCA scanner, yet every one of them can carry an executable instruction. In February 2026, Snyk researchers audited 3,984 Agent Skills pulled from ClawHub and skills.sh and found that 36.82% carried at least one security issue, with 13.4% rated critical. That study was possible because Snyk's AI-BOM tooling first has to find these prompt-bearing files before it can judge them. This piece walks through the publicly documented mechanics of how Snyk's AI-BOM identifies prompt files and prompt-injection surface area, and where Safeguard fits into hardening what gets found.
What Is Snyk AI-BOM and When Did It Ship?
Snyk AI-BOM is a component of the Snyk AI Trust Platform, launched May 28, 2025, and it generates a CycloneDX-formatted inventory of every AI asset in a codebase — models, datasets, agents, and (as of an August 4, 2025 update) MCP servers. The tool is invoked via the snyk aibom CLI command and is explicitly pitched as solving "shadow AI": the gap between the AI components a security team assumes exist and the ones actually wired into production code. Rather than asking developers to self-declare what AI they've integrated, AI-BOM scans the repository directly and produces a structured, human-readable bill of materials covering component versions, licenses, suppliers, and usage context — the same governance model SBOMs apply to open-source dependencies, extended to models, prompts, and agent tooling.
How Does AI-BOM Find AI Components Without a Manifest?
It relies on Snyk's DeepCode static analysis engine to recognize AI usage patterns directly in source code, not just in dependency manifests. Snyk describes this as necessary because AI integration is often "as simple and opaque as invoking a single API endpoint" — a single call to OpenAI's GPT-4 API or a Hugging Face transformers import may be the only signal that a model is embedded in an application, with no package.json entry or requirements.txt line that flags it as an "AI dependency" in the way a normal library would. DeepCode's code-property-graph approach — the same engine underlying Snyk Code's SAST scanning — lets AI-BOM trace these calls through the codebase and attribute them to specific files, functions, and frameworks (the documentation names Hugging Face transformers, OpenAI's API, and smol-ai agent frameworks as detected patterns), rather than matching on file extensions or hardcoded strings alone.
How Does It Specifically Identify Prompt Files and MCP Tool Definitions?
For MCP, AI-BOM scans code for known client-library usage patterns rather than a fixed list of filenames. Publicly documented detections include the standard Python mcp library (ClientSession, stdio_client, streamablehttp_client), pydantic-ai, openai-agents, langchain-mcp-adapters, and smolagents. When it finds, for example, a stdio_client call pointing at a local script, it maps the dependency chain from the calling application through the MCP client to the MCP server process and on to the individual tools that server exposes, then represents that chain as CycloneDX AI-BOM entries. For Agent Skills specifically — the SKILL.md-based packaging format popularized by registries like ClawHub — Snyk's tooling locates the SKILL.md manifest and any auxiliary executable files bundled alongside it, since Snyk's research notes that "attackers can maintain innocent-looking Skill descriptions while hiding malicious functionality in auxiliary files" shipped in the same package.
How Does Snyk Distinguish a Prompt File From Prompt-Injection Surface Area?
Finding a prompt file is inventory; deciding whether it's exploitable is analysis, and Snyk uses its mcp-scan engine for the second step. Once a SKILL.md, tool definition, or MCP schema is identified, mcp-scan applies what Snyk describes as "customized models combined with deterministic rules" — pairing pattern-based checks (regex-style detection of known-bad constructs like piped curl-to-bash installers) with model-based judgment that can catch obfuscated or paraphrased instructions a fixed pattern would miss. In the ClawHub study, this combined approach caught 91% of confirmed malicious skills' prompt-injection payloads and 100% of their malicious-code patterns, against a 0.0% false-positive rate on the top 100 legitimate skills examined for those same two categories — a gap Snyk attributes to natural-language instructions being interpretable by an agent in ways a static string match won't flag, which is also why 76 of the flagged skills required human-in-the-loop confirmation before being labeled malicious.
What Do the SKILL.md Attack Patterns Actually Look Like?
Three patterns recur across the flagged skills, per Snyk's public writeup: external malware distribution via password-protected ZIP files or curl -sSL ... | bash installers embedded in a markdown code block; obfuscated data exfiltration using base64 encoding or Unicode smuggling to slip credential-stealing instructions past a casual read; and security disablement, where a skill attempts to jailbreak the host agent or plant a persistent backdoor. The core exposure is structural — a SKILL.md's markdown code blocks are executed by an agent as commands, not rendered as inert documentation the way a human reader would treat them, so instructions embedded there carry the same weight as an explicit tool call. Snyk's data also shows non-prompt-injection risk sitting alongside it in the same files: 10.9% of all ClawHub skills examined contained hardcoded secrets, and 17.7% pulled in third-party content the skill author didn't originate.
What Should Teams Do With an AI-BOM Once They Have One?
An inventory only pays off if it drives a decision — approve, quarantine, or block a component before it reaches a running agent. AI-BOM's CycloneDX output is designed to plug into existing SBOM tooling and policy engines, and Snyk frames the MCP dependency chain (application → client → server → tool) explicitly so a team can decide, tool by tool, which ones a given agent should be allowed to call. That said, the public documentation is inventory- and detection-focused; it does not describe built-in enforcement that stops a flagged skill from running, so teams generally still need a separate control point — CI gating, runtime policy, or manual review — to act on what the AI-BOM and mcp-scan findings surface.
How Safeguard Helps
Safeguard's software supply chain platform is built for exactly this handoff: turning an AI or software component inventory into an enforceable gate rather than a static report. Where AI-BOM tooling excels at discovering and classifying prompt-bearing files, model dependencies, and MCP tool chains, Safeguard focuses on continuously monitoring the artifacts and build pipelines that ship those components into production — verifying provenance, flagging unreviewed changes to agent configurations and skill packages, and giving security teams a policy layer to quarantine or block components (AI-derived or otherwise) before they reach a deployed environment. For organizations running Snyk AI-BOM or similar discovery tooling, Safeguard complements that visibility with SOC 2-aligned controls over how those discovered components move through the build and release process, closing the gap between "we found a risky skill" and "that skill can no longer ship."