SAN FRANCISCO — Two years ago, "AI security" was a subplot inside broader cybersecurity conversations — a slide in a vendor's roadmap deck, a paragraph in a risk framework. Today it is a line item. Security teams are hiring for it, boards are asking about it, standards bodies have published frameworks for it, and acquirers have paid real money for it. What started as a loose set of concerns about chatbots leaking data has hardened into something the industry increasingly treats as its own product category: security for AI.
The distinction matters, and it's easy to blur. "AI for security" — using machine learning to detect malware, triage alerts, or write detection rules — has been a marketing staple for a decade. "Security for AI" is the inverse problem: protecting the models, prompts, training data, agents, and infrastructure that now sit inside production software. It is a newer, narrower, and — based on the last two years of standards activity, funding, and M&A — increasingly distinct discipline.
The Paper Trail
The clearest evidence of category formation isn't a press release; it's the standards bodies that only build frameworks once a problem is judged durable enough to warrant one.
NIST published its AI Risk Management Framework (AI RMF 1.0) in January 2023, giving organizations a shared vocabulary for governing AI risk. It followed up in July 2024 with a Generative AI Profile (NIST AI 600-1), addressing risks specific to large language models — hallucination, data memorization, and content provenance among them. Around the same time, OWASP's community effort to catalog LLM-specific vulnerabilities — prompt injection, insecure output handling, training data poisoning, excessive agency — matured from a side project into the OWASP Top 10 for LLM Applications, now maintained under the broader OWASP GenAI Security Project. MITRE extended its ATT&CK methodology into ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems), mapping real-world adversarial techniques against machine learning systems the same way ATT&CK maps techniques against traditional infrastructure.
Regulators moved in parallel. The EU AI Act entered into force in August 2024, introducing phased, risk-tiered obligations that reach general-purpose AI providers and, eventually, most organizations deploying AI in the EU market. Whatever one thinks of the Act's substance, its existence is itself a signal: lawmakers concluded AI systems needed security and governance obligations distinct from ordinary software.
Gartner named AI TRiSM — AI Trust, Risk and Security Management — as a strategic technology trend, giving analysts and buyers a label to organize spending around. Labels like that tend to show up only after enough vendors and enough deals exist to justify a category name. That happened here too.
The Money Followed the Framework
Standards create vocabulary; acquisitions confirm a market. Over the past two years, established security vendors have paid to acquire capability rather than build it from scratch — a classic signal of a category that has moved past the experimental phase.
Cisco acquired Robust Intelligence, an AI firewall and model-testing startup, folding it into what became Cisco AI Defense. Palo Alto Networks acquired Protect AI, whose products focused on scanning machine learning models and securing AI development pipelines. SentinelOne acquired Prompt Security, a startup built specifically around detecting and blocking prompt injection and unsafe LLM outputs. Independent vendors — HiddenLayer, Lakera, and CalypsoAI among them — built standalone businesses around model scanning, adversarial testing, and runtime guardrails, drawing venture investment specifically because incumbents didn't yet have an answer.
None of these deals happened because buyers wanted "AI features" bolted onto existing dashboards. They happened because enterprise customers were shipping LLM-powered products faster than their existing security stack could evaluate them, and the gap was wide enough to be worth paying for.
What the Category Actually Covers
"Security for AI" is not one product; it is a stack, and the stack is still being named. In practice it spans:
- Model and pipeline scanning — checking pretrained models (often pulled from public hubs like Hugging Face) for embedded malicious code, unsafe deserialization, or tampering before they enter a production pipeline.
- Prompt-layer defense — detecting prompt injection, jailbreak attempts, and data exfiltration attempts at the input/output boundary of an LLM application.
- AI red-teaming and adversarial testing — deliberately probing models for unsafe outputs, bias, or manipulation resistance before release, echoing the MITRE ATLAS technique catalog.
- AI-SPM (AI security posture management) — inventorying which models, datasets, and AI services are in use across an organization, since most security teams currently cannot answer that question with confidence.
- Governance and provenance — tracking where training data and model weights came from, who fine-tuned them, and whether they can be trusted — the AI analogue of a software bill of materials.
That last item is the thread connecting this new category back to a much older one.
Why This Is a Supply Chain Problem
Strip away the LLM-specific vocabulary and a familiar pattern emerges. A model pulled from a public hub is, functionally, a third-party dependency — no different in kind from an open-source package pulled from npm or PyPI, except that its "code" is a few gigabytes of opaque weights instead of readable source. A fine-tuning dataset is an upstream input whose integrity nobody has verified. An AI coding agent that writes and merges pull requests is a new class of committer with no security awareness of its own. None of this is really a new problem; it's the software supply chain problem, wearing a new hat.
That's precisely why the emergence of "security for AI" as a category should matter to any team that has already spent the last several years building software supply chain security programs — SBOMs, provenance attestation, dependency scanning, CI/CD hardening. The organizations most exposed to AI-specific risk today are, disproportionately, the ones that treated models, weights, and AI-generated code as somehow outside the scope of their existing supply chain controls.
How Safeguard Helps
Safeguard's premise is that AI security isn't a parallel discipline to software supply chain security — it's an extension of it. The same questions that matter for a third-party npm package matter for a third-party model: Where did it come from? Who touched it before it reached us? Does it match what it claims to be? Has it changed since we last trusted it?
Safeguard applies that lens across the pipeline:
- Provenance and SBOM/ML-BOM coverage. Safeguard extends bill-of-materials practices beyond traditional dependencies to the models, weights, and datasets flowing into AI-enabled products, so teams can answer "what AI is actually in our software" with evidence rather than a guess.
- Detecting malicious and typosquatted packages in AI toolchains. The same techniques attackers use to slip malicious packages into npm and PyPI are now showing up in AI/ML tooling and model repositories. Safeguard's dependency and package analysis extends to these ecosystems, flagging suspicious or tampered artifacts before they reach a build.
- Scanning AI-generated code with the same rigor as human-written code. As AI coding assistants and autonomous agents contribute an increasing share of commits, Safeguard treats their output like any other unreviewed code — subject to static analysis, dependency checks, and policy gates before it merges.
- CI/CD and pipeline hardening for AI workflows. Model training and fine-tuning pipelines run through CI/CD systems just like traditional builds do, and inherit the same risks — exposed secrets, unpinned dependencies, unverified artifacts. Safeguard's pipeline security controls apply there without requiring a separate toolchain.
- Continuous monitoring, not point-in-time scanning. Models and their dependencies change after deployment — a hub can update weights, a package maintainer account can be compromised, a dependency can be yanked and replaced. Safeguard treats AI supply chain risk as a continuous signal to track, consistent with how it already treats traditional software supply chains.
The emergence of "security for AI" as its own category is a useful signal — it means the industry has stopped treating AI risk as a footnote. But for teams that have already invested in supply chain security discipline, the right response isn't to stand up a second, parallel security program. It's to recognize that models, datasets, and AI-generated code are simply the newest entrants into a supply chain they already have the tools and the muscle memory to secure — provided those tools are extended to cover them. That's the gap Safeguard is built to close.