The Question
Every enterprise security leader knows they need an AI security program. The harder question is where to start and in what order to build it. Buy tools first? Hire staff first? Write policy first? Commission a red team? Stand up a monitoring platform?
The sequence matters more than most buyers appreciate. An AI security program built out of order produces islands of capability that do not connect into a coherent defense. Money gets spent, controls get deployed, and the organization still has no reliable way to detect or respond to an AI security incident.
The Stackcurve AI Security Maturity Model — five pillars built on the OWASP Top 10 for Large Language Model Applications and the five agentic threat classes — describes both what to build and the sequence to build it in. The pillars are not independent; each depends on the one before it.
Why This Matters Now
Stackcurve's research found that roughly 30% of enterprises have not held a single formal discussion about agentic AI security. For that cohort, the question of sequence is urgent — they are building from zero while their AI deployment footprint continues to grow.
But the sequence problem is not limited to organizations starting from scratch. Many enterprises that have made AI security investments have done so in response to specific incidents, vendor pitches, or compliance requirements — acquiring point solutions without a program architecture to connect them. The result is a collection of controls rather than a program: a guardrail product here, a governance tool there, a red team engagement that produced a report nobody actioned.
The difference between a collection of controls and a program is architecture and sequence. The Stackcurve Maturity Model provides both.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Security CURVE™ Report introduces the AI Security Maturity Model as a five-pillar framework for enterprise program building. The pillars are Contain, Detect, Respond, Recover, and Govern — deliberately sequenced because each pillar depends on the one before it being in place.
The enterprises Stackcurve assessed with the most mature AI security postures shared a consistent pattern: they had built in sequence, resisted the temptation to skip pillars, and treated the maturity model as a genuine progression rather than a checklist to complete simultaneously.
The enterprises with the most fragmented postures had typically skipped directly to later pillars — deploying detection tooling before containment was established, for example, or building governance frameworks before there was anything to govern. The result in each case was capability that could not deliver its intended value because its foundation was absent.
The full maturity model and vendor landscape are in the 2026 AI Security CURVE™ Report — free to download.
The Gap Most Buyers Miss
The most common sequencing failure is buying detection before establishing containment. Detection tools — behavioral monitoring, anomaly detection, SIEM integration for AI workloads — require a behavioral baseline to function. A behavioral baseline requires a defined operational scope for each AI workload: what tools it uses, what data it accesses, what API calls are normal for its task. That scope definition is the containment pillar.
Without containment — defined boundaries, enforced permissions, documented operational scope — detection generates noise. Everything looks anomalous when you have no definition of normal. Security teams that deploy detection into an uncontained environment quickly find the alert volume unmanageable and tune the sensitivity down until the monitoring is effectively disabled.
The second common failure is writing governance policy before controls exist to enforce it. An AI acceptable use policy that prohibits employees from submitting sensitive data to external AI tools is valuable. It is meaningless without the monitoring, DLP controls, and enforcement mechanisms that would detect and respond to violations. Policy without enforcement is documentation, not security.
The correct sequence follows the Maturity Model exactly: Contain first, then Detect against the baseline containment establishes, then build Respond capability against what detection surfaces, then build Recover procedures for the incidents response addresses, then build Govern as the institutional layer that makes the whole program auditable and sustainable.
The Five Pillars in Sequence
Pillar 1 — Contain Establish operational boundaries for every deployed AI workload before adding any other control. Containment means: every AI system has a defined scope, enforced permissions, and documented tool access. No agent holds standing broad permissions. No AI workload can reach systems outside its declared operational boundary.
Containment is an infrastructure-layer control enforced independently of the model. It is validated at deployment and reviewed continuously. Without it, every subsequent control has an undefined blast radius.
Maturity Level 1: Baseline. Without containment, detection is meaningless.
Pillar 2 — Detect Deploy behavioral telemetry on all Tier-1 AI workloads and run it long enough to establish a baseline. Detection operates at the semantic level — intent and sequence, not just syntactic form — because AI threat indicators are behavioral, not signature-based. An agent making unusual API calls is an indicator. An agent pursuing sub-goals not specified in its task is an indicator. Neither has a malware signature.
Detection builds on the containment baseline: anomalies are defined relative to the declared operational scope.
Maturity Level 2: Active Monitoring. Builds on containment telemetry.
Pillar 3 — Respond Build AI-specific incident response procedures mapped to the five threat classes and the seven kill-chain stages. Response playbooks for AI incidents differ materially from traditional IR: the threat may be reasoning about its environment, may have persisted state across a memory wipe, and may be exploiting legitimate tool access rather than malware. Response must be faster than the threat, and automated playbooks are essential for the early kill-chain stages.
Maturity Level 3: Active Defense. Requires mature detection.
Pillar 4 — Recover Define procedures for restoring AI systems to verified safe operational states after an incident. Recovery for AI systems is not a restart — it requires alignment re-verification, integrity validation of model weights and memory stores, and a documented chain of custody through the recovery process. A model that has been subject to memory poisoning cannot simply be restarted and declared clean.
Maturity Level 4: Resilience. Closes the loop between incident and safe redeployment.
Pillar 5 — Govern Build the institutional layer: continuous policy, compliance management, audit trails, and board-legible reporting. Governance is what makes the program sustainable and auditable. It includes AI security policy, vendor risk management for AI components, regulatory compliance tracking, and the metrics that allow the board and executive team to understand the organization's AI security posture.
Maturity Level 5: Institutional. AI security becomes an organizational capability.
Questions Your Buying Team Should Be Asking
1. Which pillar are we currently at, honestly? Assess your current state against each pillar before planning the next investment. Most enterprises overestimate their pillar progression — they have partial capability at multiple pillars without full capability at any. Establish your honest baseline before prioritizing.
2. Are we trying to skip pillars? If your current AI security investment plan includes detection tooling but your containment is not established, you are about to spend money on capability that will not deliver its value. Sequence the investments correctly.
3. Do we have a threat-class-to-incident-response mapping? The Respond pillar requires response procedures for each of the five threat classes. Does your current IR playbook address Agentic Escape? Goal Misgeneralization? If not, the Respond pillar is incomplete regardless of what tooling you have deployed.
4. Can we demonstrate our AI security posture to the board? The Govern pillar is not complete until the program is board-legible — until you can present a clear picture of your AI deployment inventory, your current maturity level, your known gaps, and your investment roadmap. If that presentation does not yet exist, governance is incomplete.
5. What is our three-year maturity roadmap? A mature AI security program is a multi-year build. A three-year roadmap — current state, 12-month targets, 24-month targets, 36-month targets — is the planning artifact that turns the maturity model from a framework into a program.
The Stackcurve Take
The organizations that will have mature AI security programs in 2028 are the ones building them in the right order today. The maturity model is not aspirational — it is descriptive of the actual dependency structure between the controls. Containment enables detection. Detection enables response. Response enables recovery. Governance connects them all into an auditable institutional capability.
Resist the vendor pressure to skip ahead. Every AI security vendor sells you their specific control — guardrails, monitoring, red teaming, governance tooling. None of them tell you to build the pillar before theirs first. That sequencing judgment belongs to the buyer, not the vendor.
Build Pillar 1 completely before purchasing Pillar 2 tooling. The discipline is difficult when the sales pressure runs in the opposite direction. The programs that follow it are the ones that deliver coherent protection rather than disconnected point solutions.
The 2026 Stackcurve AI Security CURVE™ Report covers the vendor landscape across all five maturity pillars and can be used as a sourcing guide for each stage of your program build. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.