Enterprise security teams have spent the last decade building Application Security Posture Management (ASPM) programs: consolidated inventories of code, dependencies, and cloud configurations, scored and prioritized by exploitability and business context. Generative AI broke that model. A single "AI feature" now touches a foundation model API, a fine-tuned checkpoint, a vector database, a prompt template, and increasingly an autonomous agent wired into an MCP (Model Context Protocol) server — none of which show up in a traditional SBOM or cloud asset graph. Snyk's answer, formalized as Evo AI-SPM and reaching general availability on March 23, 2026, is to extend the ASPM discipline rather than replace it: same core loop of discover, assess, enforce, monitor, but re-pointed at models, datasets, prompts, and agents instead of just packages and containers. This piece walks through how that extension is documented to work mechanically, using Snyk's own public materials, and where Safeguard fits alongside it.
What is AI-SPM, and how does it extend ASPM concepts?
AI-SPM is Security Posture Management applied to the AI asset lifecycle instead of just the application lifecycle. Where classical ASPM inventories source code repositories, open-source dependencies, containers, and cloud resources and scores them by exploitability and exposure, AI-SPM applies the same inventory-assess-enforce-monitor loop to a different set of objects: training datasets, foundation and fine-tuned models, model-serving APIs and inference endpoints, prompt templates, and — as of Snyk's 2025–2026 releases — autonomous agents and the MCP servers and tools they call. Snyk Labs describes the relationship in a single line: "AI-SPM defines the discipline. AI-BOM delivers the proof." In other words, AI-SPM is the governance layer (policies, scoring, enforcement) and the AI-BOM is the evidence layer underneath it (what AI assets actually exist and how they're wired together). Snyk frames this as a four-stage maturity model organizations move through: inventory and visibility, risk assessment, policy enforcement, and continuous validation, with red-teaming as the top rung.
How does Snyk's Evo AI-SPM actually discover AI assets in a codebase?
Discovery runs through a dedicated Discovery Agent that scans source code, pipelines, and infrastructure to build what Snyk calls a "code-first attack surface" map. According to Snyk's March 23, 2026 launch materials, this agent identifies embedded models, dataset references, agent frameworks, and MCP server connections directly from repositories and CI configuration, rather than relying solely on runtime traffic inspection. That map feeds the AI-BOM, and Snyk's documentation states it is re-evaluated on every commit or dependency update rather than generated as a one-time snapshot — the same "continuously refreshed" premise Snyk applies to its regular SBOM tooling. Snyk's published use cases give a sense of what this catches in practice: one described scenario involves detecting an unauthorized open-weight model (referred to as a "DeepSeek scenario" in Snyk's materials) before it reached production and triggered a licensing violation; another describes discovering a hidden LLM introduced through an MCP server — so-called shadow AI — that wouldn't have appeared in a conventional dependency scan because it was invoked at runtime through a tool-calling interface rather than declared as a package import.
What is an AI-BOM, and how is it different from a traditional SBOM?
An AI-BOM is a bill of materials for AI-specific components, and Snyk's version, which reached general availability on December 4, 2025, extends the concept beyond package-level manifests. A traditional SBOM lists libraries, versions, and licenses. Snyk's AI-BOM instead graphs clients, MCP servers, tools, models, and the connections between them, aiming to answer questions an SBOM was never built to answer: which model is actually serving a given endpoint, which agents can invoke which tools, and whether a fine-tuned checkpoint traces back to an approved base model. Snyk positions this as necessary because AI supply chains are dynamic in a way traditional software supply chains are not — a model can be swapped, an agent can call a new tool, or a prompt can be updated without any change to a package.json or requirements.txt file that a classic SBOM scan would catch.
How does Snyk turn AI-SPM policy into enforceable controls?
Policy enforcement runs through a Policy Agent that translates plain-English governance statements into machine-enforceable guardrails executed inside CI pipelines. Per Snyk's launch documentation, security teams write intent (for example, restricting which model providers are approved, or requiring review before an agent gains write access to production systems) and the Policy Agent compiles that into checks that run natively during builds rather than as a separate, disconnected compliance review. Snyk describes this as answering a shift in what auditors and boards are now asking: not whether an AI usage policy exists on paper, but whether it's demonstrably enforced in the pipeline. This enforcement sits alongside a Risk Intelligence Agent, which Snyk says continuously enriches the AI-BOM with metadata such as hallucination and bias signals and other security-relevant context, so that policy decisions are made against a live risk profile rather than a static asset list.
What risks does AI-SPM specifically catch that ASPM tools miss?
AI-SPM targets threat classes that don't exist in conventional application security, including prompt injection resistance, model behavior drift, output sensitivity, and unauthorized agent-to-tool calls. Snyk's public materials describe control mechanisms aimed at these risks specifically — prompt filters and input sanitization, role-based access controls scoped to model usage, and encryption of model artifacts and logs — layered on top of continuous monitoring for behavioral anomalies like unexpected API call patterns or suspicious prompt sequences. Snyk frames its three-phase coverage model around this: an Environment phase (Agent Scan, in open preview as of the March 2026 launch) that secures the tools an agent can reach, an Artifact phase that validates what's produced during CI, and a Behavior phase (Agent Guard, in private preview) that enforces rules in real time during development and can block destructive commands as they happen. The scale problem motivating this is quantified in Snyk's own 2026 State of Agentic AI Adoption Report, which found that enterprises introduce nearly three times more untracked software components per deployed AI model than through conventional development — a gap that static, point-in-time inventories aren't built to close.
How does this fit into Snyk's broader platform strategy?
Evo AI-SPM is the inventory and governance engine underneath Snyk's Agent Security solution, which the company positions as part of a wider "AI Security Fabric" unveiled at a virtual event on February 11, 2026. That fabric is described as unifying visibility, prevention, and governance across the software development lifecycle, with Snyk Studio — reported as already deployed across 300+ enterprise customers at the time of the March 2026 GA announcement — serving as the embedded interface where these agent-driven checks surface inside developer workflows. Snyk also reported more than 500 Evo scans run during the feature's early-access period ahead of general availability. This context matters for reading the AI-SPM launch correctly: it isn't a standalone bolt-on scanner, but a component wired into Snyk's existing AppRisk and DeepCode AI infrastructure, extending posture management rather than duplicating it.
How Safeguard Helps
Safeguard's focus is software supply chain integrity — verifying that the artifacts, dependencies, and build pipelines feeding into production (increasingly including AI models and agent tooling) are what they claim to be, with provenance that can be checked rather than assumed. The AI-SPM pattern described above — discover AI assets, assess their risk, enforce policy, monitor continuously — depends entirely on the underlying inventory being trustworthy: an AI-BOM is only as good as its ability to see every model, dataset, and tool call, including ones introduced through unofficial channels. Safeguard complements this class of posture management by hardening the supply chain layer those tools depend on: verifying build provenance, flagging unsigned or tampered artifacts before they enter a pipeline, and giving security teams an independent, cryptographically verifiable record of what actually shipped. For organizations evaluating AI-SPM tooling from any vendor, the practical takeaway is that posture management and supply chain integrity are complementary controls, not substitutes — a policy engine that enforces "only approved models" is only as strong as the guarantee that what's deployed is actually the artifact that was approved. Teams building out AI governance programs should treat provenance verification as a prerequisite layer underneath whichever AI-SPM platform they adopt.
Sources: Snyk Launches Agent Security Solution; GA of Evo AI-SPM (GlobeNewswire, March 23, 2026), AI-BOM and the Future of AI Security Posture Management (Snyk Labs), Understanding AISPM: Securing the AI Lifecycle (Snyk), Introducing Agent Security (Snyk).