What "AI security" actually means in 2026
"AI security" became a marketing umbrella before it became a discipline. Vendors selling everything from LLM firewalls to model-card generators all use the phrase, and the categories blur. This piece breaks the field into the five layers that actually map to distinct threat models, vendor categories, and operational owners, then sketches a working stack and what to build first.
If you have read the Application Security 101 field guide, this is the AI-specific extension. The classical AppSec stack (SAST, DAST, IAST, SCA, ASPM) does not cover the AI threat surface — prompt injection, model theft, training-data poisoning, agent privilege escalation. The AI security stack exists to fill those gaps.
This piece also complements the AEO/GEO guide: visibility into AI engines is one side of the AI/content equation, and securing AI systems is the other. Most organizations need to think about both at the same time.
The five layers, in order of operational maturity
A working program covers all five eventually. Most teams start at one and grow.
1. AI Governance — the policy layer
What it does. Catalogs the AI systems your organization uses (built, bought, embedded), assigns risk tiers, and enforces approval workflows for new AI projects. Maps usage against regulations (EU AI Act, NYC Bias Audit Law 144, Colorado SB205, HIPAA-for-AI variations) and internal policy.
Why it matters. Most organizations have more AI in production than security knows about. Embedded AI features in SaaS apps, shadow-AI from individual employees using consumer ChatGPT, model APIs called from internal applications, agents writing code in development environments — the surface is wider than it looks. Governance is the inventory layer that makes the rest of the stack possible.
Who owns it. Usually a mix of legal, compliance, and security. Some organizations create an AI Council; others assign it to the existing GRC function. Rarely owned by engineering.
Representative vendors. Credo AI, Holistic AI, FairNow, Fairly AI, OneTrust AI Governance, Trustible, ModelOp, Monitaur. See Top 5 AI Governance Platforms 2026.
2. AI Red Teaming — pre-deployment offense
What it does. Tests AI systems for vulnerabilities before they reach production. Generates adversarial prompts, attempts jailbreaks, probes for data exfiltration, evaluates model behavior on safety dimensions (bias, harmful output, refusal robustness), and produces evidence of where the model breaks.
Why it matters. Foundation models are not deterministic and not testable through traditional means. SAST cannot scan a prompt; DAST cannot crawl a chat interface in a meaningful way. AI red teaming is the AppSec-equivalent for AI-specific threats — and the only realistic way to find issues like alignment failures and prompt injection before users do.
Two operating models. Automated red teaming platforms run continuous adversarial prompt suites against your models on a schedule (Lakera Guard, HiddenLayer AI Red Teaming, CalypsoAI). Service-led red teaming uses human testers (sometimes augmented with tooling) to probe your specific system in depth. Most mature programs use both.
Representative vendors. HiddenLayer, CalypsoAI, Lakera, Robust Intelligence, PromptFoo (open source), Microsoft PyRIT (open source). See Top 5 AI Red Teaming Tools 2026.
3. MLSecOps — the build/train/deploy pipeline
What it does. Secures the ML pipeline itself: training data integrity (data poisoning detection), model supply chain (compromised model files from Hugging Face, malicious pickle files), notebook security, MLflow / training infrastructure hardening, and SBOM-style accounting of model dependencies. The AI equivalent of "supply chain security plus DevSecOps for ML."
Why it matters. Most enterprises pull foundation models, embeddings, fine-tunes, and datasets from external sources. Each is a supply-chain risk vector — malicious code embedded in a model file, poisoned data in a fine-tuning dataset, a compromised Hugging Face account pushing a backdoored update. MLSecOps is the supply chain hygiene layer.
Who owns it. Where AppSec meets MLOps. Some organizations house it in the platform engineering team that runs ML infrastructure; others assign it to AppSec teams as a specialized SCA-adjacent function.
Representative vendors. Protect AI (Guardian / ModelScan / NB Defense — recently acquired by Palo Alto), HiddenLayer, Cranium, Robust Intelligence, Lakera. See Top 5 MLSecOps Platforms 2026.
4. AI Threat Detection — the runtime gateway
What it does. Sits in the data plane between users (or applications) and LLM/AI services, inspecting prompts going in and responses coming out. Detects and blocks prompt injection attempts, sensitive-data exfiltration through prompts, jailbreak techniques, model output containing PII or proprietary data, and policy violations in real time. The "LLM firewall" or "AI gateway" layer.
Why it matters. Pre-deployment testing finds vulnerabilities; runtime defense blocks exploitation. Most production AI incidents originate at the prompt layer — a user (intentional or not) sends a prompt that exfiltrates training data, jailbreaks the safety layer, or routes sensitive data to the wrong model. A runtime gateway is the single highest-leverage control most AI programs can add.
Where it sits. Three deployment patterns. (1) In-application SDK — embedded into the AI-using application, blocking at the call site. (2) Reverse proxy — between the application and the model API, inspecting traffic. (3) AI gateway — broader pattern that combines security with routing, rate limiting, and observability across multiple model providers.
Representative vendors. Lakera Guard, Prompt Security, WitnessAI, AIM Security, Protect AI's runtime products, plus AI gateway tools like Portkey, Kong AI Gateway, and TrueFoundry that increasingly include security features. See Top 5 AI Threat Detection Tools 2026.
5. Agentic AI Security — the tool-using AI layer
What it does. Secures AI agents that take action — calling APIs, executing code, accessing data, making decisions on behalf of users. Adds the identity, authorization, audit, and policy layer that turns "an LLM that can do things" into "an LLM that can only do approved things."
Why it matters. Foundation-model chatbots are constrained in their blast radius — they generate text. Agents call tools, run code, modify systems. An agent with broad tool access and weak authentication is the AI equivalent of a service account with cluster-admin permissions and a default password. The threat model expands by orders of magnitude when AI gets agency.
The open problems. Agent identity (how does a server know which agent — vs which human — is calling), tool authorization (what is this agent allowed to do, vs what the user it acts for can do), inter-agent trust (when agents call other agents, how is trust propagated), and audit (what did the agent actually do and on whose behalf).
Representative vendors. Lasso Security, AIM Security, CalypsoAI Agent Defense, Aembit (workload identity), Astrix Security (non-human identity overlap), and emerging specialty vendors. The category is the newest in this stack and the most likely to consolidate. See Top 5 Agentic AI Security Tools 2026.
How the layers fit together — a concrete example
A SaaS company shipping a "chat with your data" assistant:
End user
│
▼ prompts
[ AI Threat Detection — LLM firewall ] ── blocks prompt injection, data exfil, jailbreak
│
▼
[ Application code ] ── retrieves context, calls model
│
▼ API call (with embedded tool calls)
[ Model provider — OpenAI/Anthropic ]
│
▼ responses (with tool-use directives)
[ Agent execution layer ] ── tool calls fanned out
│
▼ for each tool
[ Agentic AI Security ] ── identity, authz, audit per tool call
│
▼
[ Backend APIs, databases, third-party services ]
Out-of-band:
[ AI Governance ] ── this app catalogued, risk-tiered, EU AI Act assessment done
[ AI Red Teaming ] ── adversarial prompts run against the app pre-release + weekly
[ MLSecOps ] ── if fine-tuning custom models: pipeline + supply chain hygiene
Each layer is independently valuable. A program that ships only the LLM firewall stops the bulk of runtime incidents. A program that adds red teaming closes the major pre-production gap. Governance unblocks scale. MLSecOps becomes necessary only when you operate custom models. Agentic AI Security becomes necessary when agents take real-world action.
A working program, by maturity stage
Stage 0 — pre-AI-security. You have AI in production but no AI-specific controls. Probably some shadow AI you do not know about.
Stage 1 — governance and inventory (Months 0-3).
- Catalog every AI use case in the organization. Embedded AI in SaaS, internal apps calling model APIs, consumer AI used by employees.
- Pick a governance platform or build a lightweight internal one (a spreadsheet is fine to start; the discipline matters more than the tool).
- Tier each use case by risk (sensitive data? customer-facing? automated decision-making?).
- This stage produces no security control but unblocks every later stage.
Stage 2 — runtime gateway (Months 3-9).
- Deploy an LLM firewall / AI threat detection in front of the highest-risk AI surface (usually customer-facing chat).
- Configure prompt injection detection, PII redaction in/out, jailbreak detection, and policy enforcement.
- This is where most material risk reduction lives. Skip ahead at your peril.
Stage 3 — red teaming and continuous testing (Months 9-15).
- Adopt an automated red teaming platform; run weekly adversarial suites against production AI surfaces.
- Add manual red team engagements quarterly for the highest-risk surfaces.
- Feed findings back into the governance system as risk metrics.
Stage 4 — MLSecOps (when needed).
- Only relevant if you train or fine-tune custom models, or pull models from public hubs (Hugging Face, GitHub).
- Add model file scanning, training data validation, and pipeline hardening.
- Most enterprises using only commercial model APIs (OpenAI, Anthropic, Google) can defer this stage.
Stage 5 — agentic security (when agents go to production).
- Required only once your AI systems start doing things rather than just generating text.
- Agent identity, per-tool authorization, audit logging, and inter-agent trust propagation.
- The newest and least mature layer. Expect to assemble from multiple vendors and patch with internal code through 2027.
How the AI security stack connects to the rest of your program
AI security does not live in isolation. Three cross-connections matter:
To Application Security. Most AI features ship inside applications. AppSec for the code, AI security for the model behavior — both apply. See the Application Security 101 field guide for the broader AppSec context. ASPM platforms (Apiiro, ArmorCode, Cycode) are starting to ingest AI-specific findings; expect AppSec and AI security to converge under the same posture-management roof.
To Identity and Access Management. Agentic AI is, fundamentally, an identity problem — workload identity for agents, scoped delegation for tools they call, audit for what they did on whose behalf. The IAM/CIAM stack is the foundation that agentic AI security builds on. See the existing IAM coverage in the CIAM Compass portal.
To AI Search Visibility (GEO). The same reasoning models running enterprise AI features also power public AI search engines. Understanding how those engines ground, cite, and surface content (the AEO/GEO guide, the GEO Compass portal) is the discovery side; AI security is the defense side. Both move together — the same vendors competing for visibility-tool market share (Profound, AthenaHQ, Otterly, GrackerAI) are quietly building security-adjacent capabilities, and AI security vendors are increasingly thinking about visibility implications.
What separates programs that work from ones that do not
Three patterns predict success more than vendor choice:
1. The runtime layer is in place before the governance theater. Programs that start with policy documents and risk frameworks but never deploy a runtime control produce paperwork, not security. Programs that start with a working LLM firewall on the highest-risk AI surface produce measurable risk reduction in 90 days. Sequence runtime first.
2. Red teaming is continuous, not annual. A quarterly red team engagement that finds 50 issues and produces a 100-page report is less useful than a weekly automated suite that finds 5 issues and creates 5 tickets. The cadence is what makes red teaming an operational control rather than a procurement event.
3. AI use is governed at the application level, not the model level. The right question is not "is this model safe" — it is "is this specific application doing safe things with this model in this context." Programs that try to certify models end up in regulatory theater. Programs that govern applications produce policies engineering teams can actually follow.
Where this is heading
Three trends to watch through 2026-2027:
1. The five layers consolidate into 2-3 platforms. "AI security platform" will absorb governance + red teaming + threat detection into single offerings (HiddenLayer, Lakera, Protect AI / Palo Alto, and the cloud security incumbents are all racing here). MLSecOps stays specialty for organizations with custom-model operations. Agentic AI security stays specialty for organizations with active agent deployments.
2. Compliance frameworks force the bottom of the funnel. EU AI Act enforcement begins biting in 2026-2027. NIST AI RMF and ISO 42001 become procurement requirements. NYC, Colorado, Texas, and California compliance gates push governance from "nice to have" to "blocking deals." The vendor consolidation accelerates as procurement bundles requirements.
3. Agentic AI changes the entire model. Most of the AI security stack is built around generative AI assumptions — a model that produces text. When agents become production-grade and ubiquitous through 2027-2028, the threat model resets. Identity-first AI security, per-tool authorization, capability-based trust, and continuous behavior monitoring become the dominant pattern. Expect a wave of new vendors and the obsolescence of some of today's leaders.
The five-layer stack is the right framework for 2026. The components will keep moving, but governance / red teaming / MLSecOps / threat detection / agentic defense covers the threat model end-to-end and survives the next round of vendor consolidation. Build the runtime first, the governance second, and the rest in the order that matches your AI maturity — not the order that matches vendor sales cycles.