The Question
Your organization has invested in application security tooling — a web application firewall, static analysis scanners, dynamic testing pipelines, maybe an API security platform. You are now deploying AI-powered applications. Are you protected?
The short answer is: partially. Your existing AppSec stack will catch the threats it was designed to catch. The problem is that AI applications introduce an entirely different class of vulnerability — one that your current tools were never built to see.
OWASP addresses this directly. The OWASP Top 10 for Large Language Model Applications is a separate list from the classic OWASP Top 10. The threats are different. The defenses are different. The tools are different.
Why This Matters Now
In February 2023, a Stanford student named Kevin Liu discovered that Microsoft's Bing Chat had a hidden system prompt — a set of instructions defining its persona and operational rules, labeled "Sydney." Liu extracted the full prompt by simply asking the model to "ignore previous instructions" and repeat what was written above. Microsoft had not intended this to be accessible. The system prompt contained behavioral rules, restrictions, and internal branding language that Microsoft considered confidential.
This was not a SQL injection. It was not an XSS vulnerability. No WAF rule would have caught it. No SAST scanner would have flagged it. The attack surface was entirely semantic — it existed in the meaning of text, not in code, parameters, or HTTP headers.
This is the fundamental mismatch your AppSec team needs to understand. Traditional application security operates on syntax: it looks for known patterns in code and traffic. LLM vulnerabilities operate on semantics: the threat is in the meaning and interpretation of natural language. Your existing tools are looking in the wrong dimension.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Security CURVE™ Report documents twelve market categories relevant to AI security. Two of them — AI Application Security and AI Firewall & Gateway — map most directly to what enterprise AppSec teams need for LLM deployments.
What the data shows is a market in transition. Established AppSec vendors — Salt Security, Traceable AI, Contrast Security — are extending their platforms toward LLM-specific coverage. They bring enterprise maturity, existing integrations, and familiar procurement relationships. What they are building is real. What they have shipped as of 2026 varies significantly from vendor to vendor, and in most cases the LLM-specific capability is newer, less battle-tested, and narrower in scope than their core product.
The purpose-built AI security vendors — Check Point's Lakera, Pillar Security, CalypsoAI — started from the LLM threat model and built up. Their coverage of the OWASP Top 10 for LLMs tends to be deeper; their enterprise fit and ecosystem integrations tend to lag the established players.
The enterprise buyer navigating this market is caught between maturity and capability. Neither camp has fully solved the problem.
The full vendor rankings are in the 2026 AI Security CURVE™ Report — free to download.
The Gap Most Buyers Miss
The OWASP Top 10 for LLMs includes a risk that has no equivalent in traditional AppSec: LLM07: System Prompt Leakage. Your system prompt is the instruction set that defines how your AI application behaves — its persona, its constraints, its rules. In most deployments, it is treated as a secret. In practice, it is often extractable.
The Bing Sydney incident was public and embarrassing. The more common version of this problem is quieter. Competitors, researchers, or adversaries who can extract your system prompt understand your AI application's internal logic, its restrictions, and — critically — how to work around them. A system prompt that says "never discuss competitor pricing" tells an attacker exactly what to probe. A prompt that defines the scope of an AI agent's tool access tells an attacker which tools are available to exploit.
Beyond system prompt leakage, your AppSec stack misses:
- Indirect prompt injection — attacks embedded in content the AI retrieves, not in user input your WAF can inspect
- Output-based attacks — LLM responses that contain malicious instructions for downstream systems (OWASP LLM05: Improper Output Handling)
- Agent tool-chain abuse — sequences of individually authorized tool calls that together achieve unauthorized outcomes
- Semantic jailbreaks — inputs that appear benign to a WAF but instruct the model to abandon its guidelines
None of these have syntactic signatures. All of them require a fundamentally different detection approach.
Questions Your Buying Team Should Be Asking
1. Does your existing AppSec vendor have a published mapping to the OWASP Top 10 for LLMs? Ask them for it. If they cannot produce one, their LLM coverage is likely superficial. If they can, review it critically — coverage claims on paper versus demonstrated capability in a live environment are often different things.
2. How does your WAF handle prompt injection in POST body content? Most WAFs inspect headers, parameters, and known attack signatures. Natural language in a POST body — which is where most LLM inputs live — is typically treated as opaque. Ask your WAF vendor directly whether they have LLM-specific rules.
3. What does your SAST scanner flag in AI application code? Static analysis can catch insecure model integrations — hardcoded prompts, missing output sanitization, over-permissioned API keys — but only if the rules exist. Ask your SAST vendor which AI-specific rules they have shipped.
4. How are you protecting your system prompts from extraction? This is a design question as much as a tooling question. System prompt confidentiality requires model-level controls that sit outside your traditional AppSec toolchain.
5. Where does AI application security sit in your organizational structure? AppSec teams that own LLM security without AI-specific training and tooling are carrying risk they cannot see. The ownership question matters as much as the tooling question.
The Stackcurve Take
Your existing AppSec stack is not useless for AI applications. Standard controls — authentication, authorization, API rate limiting, dependency scanning, secrets management — apply to AI applications exactly as they apply to any other application. Enforce them rigorously. The OWASP Top 10 for LLMs was not written to replace the classic OWASP Top 10; it was written to supplement it.
But the supplement is not optional. The LLM-specific risks — prompt injection, system prompt leakage, improper output handling, excessive agency — are not edge cases. They are design characteristics of LLM applications, and they require controls your current stack was not designed to provide.
The practical path forward is a gap analysis: map your current AppSec controls against the OWASP Top 10 for LLMs and identify which risks have no coverage. For most enterprises, the gaps will cluster around prompt injection defense, output validation, and system prompt protection. Those are the priority additions.
Do not wait for your existing AppSec vendors to catch up before acting. The risk is live in production today. Purpose-built LLM security controls exist — they are less mature than your existing stack, but they address threat classes your existing stack cannot see.
The 2026 Stackcurve AI Security CURVE™ Report evaluates the AI Application Security and AI Firewall & Gateway categories in detail. 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.