The Question
The AI security market has more than 140 vendors claiming some form of AI security capability. Twelve distinct sub-categories. A vendor landscape that consolidates and reshapes itself every quarter. If you are an enterprise security leader trying to determine where to start, the breadth of the market is itself a barrier.
This Advisory Brief cuts through the noise. Before you evaluate a single vendor, before you issue an RFP, before you attend a product demo — there are five foundational controls that every enterprise deploying AI should have in place. They are not the most sophisticated controls available. They are the ones that, if absent, make every other AI security investment less effective.
Together, these five controls address the majority of the OWASP Top 10 for Large Language Model Applications. They are also the foundation of the Stackcurve AI Security Maturity Model's first two pillars: Contain and Detect.
Why This Matters Now
The 2026 Stackcurve AI Security CURVE™ Report documents a finding that should alarm every enterprise security team: roughly 30% of enterprises have not held a single formal discussion about agentic AI security. Not an incomplete program — no conversation at all.
For organizations in that 30%, the instinct is often to respond by immediately evaluating vendors and purchasing tools. That instinct is understandable and wrong. The enterprises that have gotten AI security right did not start by buying products. They started by building a foundation: an inventory of what they have, a monitoring baseline to detect anomalies, a principle of least privilege applied to AI workloads, controls at the input and output boundaries, and a response protocol for when something goes wrong.
Products come after foundation. Foundation comes first.
What the CURVE™ Data Shows
The Stackcurve CURVE™ research found a consistent pattern among the enterprise security leaders who are furthest ahead on AI security: they treat AI workloads with the same rigorous control discipline they apply to their highest-risk infrastructure — not because the tools told them to, but because the asset-and-threat model demanded it.
The enterprises furthest behind share a different pattern: they are waiting for their existing security vendors to extend coverage to AI, treating AI security as a feature addition to existing contracts rather than a new capability domain requiring deliberate investment. By the time those extensions arrive, the preparedness gap has widened.
The five controls below do not require purchasing new products. Some are tooling questions; most are architecture and process questions. All five can be initiated immediately.
The full vendor rankings are in the 2026 AI Security CURVE™ Report — free to download.
The Gap Most Buyers Miss
Most enterprise AI security programs start in the wrong place — they start with detection. They deploy monitoring before they have an inventory. They instrument runtime behavior before they have established what normal behavior looks like. They buy guardrail products before they understand which AI deployments are high-risk and which are not.
Detection without a baseline produces noise. Monitoring without inventory produces blind spots. Guardrails without a risk classification produce misallocated controls — strong protection on low-risk deployments, gaps on high-risk ones.
The five controls are sequenced deliberately. Each depends on the one before it.
The Five Controls
Control 1: AI Asset Inventory Addresses: Foundation for all OWASP LLM risks
You cannot protect what you cannot see. An AI asset inventory is not a policy — it is a technical artifact: a living register of every AI and LLM system deployed in the organization, including the AI features embedded in approved SaaS, shadow deployments discovered through network monitoring, and AI integrations in business unit workflows.
The inventory should capture, at minimum: the AI system name and vendor, the data it accesses, the tools and permissions it holds, who owns it, and its risk tier (Tier 1: agentic with tool use; Tier 2: conversational with limited access; Tier 3: non-interactive processing). Tier 1 systems are your highest priority for every subsequent control.
Most enterprises that run their first AI asset inventory discover three to five times more AI deployments than their central IT register reflects. That gap is your current unmanaged exposure.
Control 2: Baseline Runtime Monitoring Addresses: OWASP LLM01 (Prompt Injection), LLM06 (Excessive Agency)
You cannot detect anomalous AI behavior without a baseline of normal behavior. Before you can know that an AI agent is making unusual API calls, you have to know what usual API calls look like. Baseline runtime monitoring means deploying lightweight behavioral telemetry on all Tier-1 AI workloads — tool-call logging, API call auditing, output sampling — and running it long enough to establish a behavioral baseline.
This does not require a purpose-built AI security product to start. Logging infrastructure you already have — SIEM, API gateways, cloud-native audit logs — can capture this data. The AI-specific behavior analysis layer comes later. The telemetry foundation can be built now.
Control 3: Least Privilege for AI Workloads Addresses: OWASP LLM06 (Excessive Agency), LLM08 (Vector & Embedding Weaknesses)
Over-permissioning is not an AI-specific failure — it is the universal security failure that AI makes dramatically more dangerous. An AI agent that holds standing access to file systems, email, databases, and APIs does not need to be compromised to cause harm: it just needs to be manipulated into using access it already legitimately holds.
The principle of least privilege applied to AI means: every AI workload holds only the access it needs for its defined task scope. No standing broad access. No inherited permissions from the user who deployed it. No access that "might be useful later." Every tool integration, every data connection, every API permission is declared, justified, and reviewed at deployment.
This is a design-time control. Retrofitting it to existing AI deployments is harder than building it in from the start. If you have Tier-1 AI workloads already in production without a least-privilege audit, that audit is your immediate priority.
Control 4: Input and Output Guardrails Addresses: OWASP LLM01 (Prompt Injection), LLM02 (Sensitive Information Disclosure), LLM05 (Improper Output Handling)
Guardrails are the controls that sit at the boundary of your AI system — inspecting what goes in and what comes out. Input guardrails detect and block prompt injection attempts, data-type violations (PII, source code, credentials), and policy violations before they reach the model. Output guardrails inspect model responses for sensitive data leakage, harmful content, and instructions intended for downstream systems.
The key insight from the CURVE™ research: guardrails are most effective when deployed against a defined risk policy — specific data types to block, specific output categories to flag — rather than as generic "AI safety" filters. A guardrail without a policy is a speed bump. A guardrail with a clear policy is a control.
Start with your highest-risk AI applications: those that handle regulated data, those with external-facing interfaces, those where a malicious output could take real-world action.
Control 5: AI Incident Response Protocol Addresses: Cross-cutting — applies to all five Stackcurve threat classes
AI incidents do not look like traditional security incidents. An AI agent executing a tool-chain compromise does not trigger a malware alert. A goal misgeneralization event does not produce a failed login. An indirect prompt injection that exfiltrates data through an authorized API call leaves no malicious signature for your SOC to catch.
Your existing incident response playbook was not written for these scenarios. The fifth foundational control is an AI-specific IRP addendum: mapped to the five agentic threat classes (Agentic Escape, Goal Misgeneralization, Memory Poisoning, Tool Chain Compromise, Recursive Self-Modification), defining detection indicators, containment procedures, and escalation paths for each. Run a tabletop exercise against an agentic-escape scenario within 60 days of completing the other four controls.
The Stackcurve Take
These five controls are not a complete AI security program. They are the foundation without which a complete program cannot be built. An enterprise with all five in place — inventory, monitoring baseline, least privilege, guardrails, and incident response — is positioned to evaluate AI security products intelligently, to allocate budget to actual gaps rather than perceived ones, and to respond when something goes wrong.
An enterprise without them is buying products before it has walls to hang them on.
Implement in order. The inventory tells you where to focus monitoring. The monitoring baseline tells you what least privilege should look like. The guardrails protect the highest-risk surfaces the inventory identified. The incident response protocol ties it together. Skipping steps creates gaps; following the sequence builds compounding coverage.
The 2026 Stackcurve AI Security CURVE™ Report provides the vendor landscape for each control layer. 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.