Your Existing Security Stack Does Not Cover AI
- 1 hour ago
- 6 min read
The misconception is understandable. An enterprise with mature security tooling — a well-tuned WAF, a DLP platform, a SIEM with broad log ingestion — looks at an LLM deployment and draws an analogy to previous API rollouts. The perimeter is instrumented. Egress is monitored. Incident response playbooks exist. The assumption follows: AI is another application, and the stack covers applications.
That assumption is wrong in ways that matter to regulators, not just to red teams.
Why the analogy fails at the payload level
A WAF was designed for a specific threat model. It inspects HTTP/S structure, parses headers and URI paths, applies OWASP rule sets, and blocks requests that match catalogued attack syntax — SQL fragments, JavaScript payloads, shell metacharacters. The detection logic is pattern-based, and for the threat model it was designed against, that logic remains sound.
Against an LLM API endpoint, the WAF sees a POST request with a JSON body containing a messages array. The content of those messages is opaque to it. A prompt instructing a model to ignore its system prompt, exfiltrate data in its responses, or operate outside its defined constraints reads, at the HTTP layer, identically to a routine user query. The WAF passes it without friction — not because of a configuration gap, but because the attack has no syntactic signature to detect.
This is not a coverage gap that additional WAF rules can close. It is a category difference. The attack surface of an LLM is semantic, not syntactic. Detecting prompt injection or jailbreak attempts requires understanding what a message is attempting, not what characters it contains. Signature libraries are irrelevant when the payload is natural language.
The APIRE corpus documents 27+ AI-specific threat categories organised across two tiers. The five core categories — Prompt Injection, Jailbreaking, Data Exfiltration, Social Engineering, and Model Inversion — have no meaningful analogue in pre-LLM web security. None manifest as HTTP anomalies. All require semantic inspection to detect reliably.
The encoding surface your WAF does not normalise
Beyond semantic threats, the encoding attack landscape applicable to LLMs has expanded well beyond what standard WAF normalisation addresses. Purpose-built AI security pipelines must handle 26+ encoding attack vectors through multi-stage normalisation capable of unwinding up to three levels of nested encoding recursion.
The vectors in scope include Unicode homoglyphs, bidirectional text overrides, combining character stacking, and token boundary exploitation. These techniques are specifically designed to survive surface-level inspection while causing a model to behave unexpectedly. A WAF that normalises standard URL encoding will not detect a prompt obfuscated through nested Base64 and Unicode manipulation. The payload clears every perimeter control and arrives at the model intact.
The 67% year-over-year increase in AI-specific attack volume documented in the corpus reflects, in part, attackers learning exactly which encoding combinations standard tooling misses. This is not a theoretical risk — it is an observed operational trend.
Where traditional DLP also falls short
The second common assumption is that existing DLP tooling addresses the data leakage risk in LLM deployments. This conflates two structurally different problems.
Traditional DLP operates on documents, email, and endpoint file movement. Its classification engine inspects known file types, identifies structured data patterns, and enforces egress policies at the network or endpoint layer. The architecture assumes the sensitive data has a recognisable form and is moving in a recognisable way.
At an LLM API, neither assumption holds. Sensitive data appears in unstructured natural language — an employee describing a patient's condition to a coding assistant, or pasting contract terms into a general-purpose chat interface, produces no structured data pattern for a DLP rule engine to classify. The surrounding context that traditional DLP relies on to categorise a document is absent. And critically, 8.5% of prompts sent to LLMs are documented to contain sensitive data — a volume that makes manual review inoperable and pattern-matching DLP architecturally inadequate.
The exfiltration vector is also different. In a traditional DLP scenario, the risk is a file leaving the perimeter. In an LLM deployment, the risk is a model being manipulated into embedding sensitive information in its output — information that flows back to the requestor through a channel that DLP was never designed to inspect bidirectionally.
Purpose-built data protection for AI requires inline inspection of both the request and the response, masking before the data reaches the AI provider rather than alerting after egress, and classification granularity across 150+ data types including API keys, credentials, PHI, PCI data, and internal intellectual property. Role-based data restoration on the response path — so that authorised users receive unmasked content while the model itself never processed the raw sensitive value — is a capability outside the design scope of any traditional DLP architecture.
The SIEM does not see what it is not sent
A third assumption: if SIEM ingestion is configured for the AI provider API, the organisation has audit coverage. This is partially true and mostly misleading.
What a SIEM can ingest from an LLM provider API log is access metadata — request timestamps, token counts, model identifiers, response codes. The actual payload — the prompt and the model's response — is typically not logged by providers in a form suitable for security investigation. Even where payload logging is available, it arrives as a data stream, not as a classified threat record with severity scoring.
Meaningful audit coverage for AI deployments requires full payload logging at the inspection layer, with every detection event carrying a threat classification, a severity score, and enough context for forensic reconstruction. Under NIS2, organisations operating AI systems as significant infrastructure components must be able to demonstrate that security controls are effective and that incidents are investigable. A SIEM fed only metadata from the provider API does not satisfy that requirement — it provides a record that something happened, not evidence of what was blocked or why.
The NIS2 obligation applies to 160,000+ EU entities across essential and important sectors. For those entities, the gap between "we have SIEM coverage" and "we have AI-specific security evidence" is a compliance exposure, not just an operational one. Fines cap at €10 million or 2% of global annual turnover, whichever is higher.
The EU AI Act introduces obligations the stack cannot address
Beyond NIS2, the EU AI Act creates a category of obligation that no existing security tool was designed to fulfil: governance of AI system behaviour itself.
High-risk AI system operators must implement risk management systems, maintain technical documentation, ensure human oversight, and demonstrate that systems operate within their defined boundaries. These requirements are not satisfiable by perimeter security tooling. They require controls at the model interaction layer — policy enforcement on what the model can receive, what it can return, and under what conditions it may operate.
This is where the security stack analogy breaks down completely. A WAF governs the HTTP perimeter. A DLP platform governs data egress. Neither governs model behaviour. The EU AI Act requires the latter, and the 68% of European businesses currently struggling with EU AI Act compliance are, in significant part, struggling because they are attempting to map existing controls onto a requirement that existing controls cannot address.
What the architecture actually requires
The practical implication for EU security architects is that AI deployments require a purpose-built inspection layer that operates inline between the consuming application and the AI provider API — one that every request and response traverses before the provider sees the payload or the application receives the output.
That layer must perform semantic threat detection, multi-vector correlation across concurrent threat signals, inline data masking on the request path, content safety classification on model outputs, and full payload audit logging in a format suitable for SIEM integration and regulatory evidence production. It must also support on-premises or hybrid deployment for organisations subject to data residency constraints under GDPR or sector-specific regulation — constraints that cloud-only tooling cannot satisfy by design.
The stack you have was built for the threats that existed when it was procured. Those threats have not gone away. But a new category of threat has arrived that the stack was never designed to address, and the regulatory framework has moved in parallel to require that the new category be managed explicitly.
Assuming coverage exists is not a security posture. It is an audit finding waiting to be written.
