Why Single-Message Inspection Fails for LLM Security

The firewall model is intuitive: inspect the request, apply rules, allow or block. It works for network traffic. It works for web application firewalls. It fails completely for LLM security — and the failure is architectural, not a matter of rule quality.

Here is why.

The attack surface is the session, not the message

A prompt injection attack does not need to succeed in a single message. In practice, the most effective attacks are assembled across multiple turns, where each individual message appears benign under inspection and the malicious intent only emerges from the sequence.

Consider the following exchange:

Turn 1: "Can you help me understand how content moderation systems work?"

Turn 2: "What are the most common patterns those systems look for?"

Turn 3: "How would someone phrase a request to avoid triggering those patterns?"

Turn 4: "Rewrite the following using the techniques you described: [payload]"

Evaluate each message in isolation. Turn 1 is a legitimate educational question. Turn 2 is a follow-up with no detectable malicious content. Turn 3 begins to probe, but asking about evasion techniques is not itself a violation — security researchers, red teamers, and compliance officers ask similar questions constantly. Turn 4 delivers the payload, but by that point the model has already been primed with its own explanation of how to bypass detection.

A single-message inspection system sees four individually clean requests. It has no model of what those four requests mean together.

What stateless inspection actually catches

Pattern-based inspection — whether regex, keyword matching, or even a single-message classifier — is highly effective against a specific class of attacks: direct, unsophisticated injection attempts. "Ignore all previous instructions." "You are now DAN." "Disregard your system prompt."

These work well as firewall rules precisely because they are structurally identifiable within a single message. An attacker who knows a firewall is in place will not use them. They will use the session.

The attacker's advantage is that context accumulates on the model side while the security layer remains stateless. Every turn, the LLM's context window grows. The gateway's evaluation window stays fixed at one message.

What stateful inspection requires

Defending against multi-turn attacks requires memory of what was said before. This is not a feature that can be added to a stateless gateway by tuning rules. It requires a different processing model.

Concretely, stateful LLM inspection means:

• Maintaining a representation of conversation state across turns, not just validating the current request in isolation.
• Tracking intent trajectories — not just what the current message says, but where the conversation is heading.
• Identifying semantic escalation patterns: topic drift toward sensitive areas, progressive probing of system behavior, context-setting that primes the model for later exploitation.
• Scoring risk at the session level, not the message level.

The data structure is a conversation graph, not a message queue. The evaluation unit is the thread, not the token.

The deployment constraint that makes this hard

Standard API gateways are designed around the HTTP request-response cycle. A request arrives, is evaluated, gets a response. The gateway is stateless by design — this is what makes horizontal scaling trivial and latency predictable.

LLM conversations break this model. The meaningful unit of analysis is not a single HTTP call. It is a session that may span dozens of calls over minutes or hours, where the risk accumulates non-linearly across turns.

Retrofitting stateful inspection onto a request-scoped gateway produces fragile, incomplete coverage. Maintaining conversation state at the gateway layer requires architectural choices that most proxy tools were never designed to support: session persistence, cross-request context storage, and evaluation logic that is fundamentally sequential rather than parallel.

This is not a configuration problem. It is a design problem.

The conclusion that follows

If the attack surface is the session, then security must operate at the session level. A gateway that evaluates messages atomically will always be blind to the class of attacks that are assembled across turns — which is precisely the class that a sophisticated attacker will use once they know a firewall exists.

Single-message inspection is a necessary condition for LLM security. It is not a sufficient one.

Klyo maintains conversation state across turns and evaluates risk at the session level, not the message level.