Detecting Prompt Injection With Your SIEM

Overview#

Prompt injection has held the top spot on the OWASP list for large language model applications across two editions in a row. Most teams fight it at the application layer with input filters and model guardrails. Those help but they share one blind spot. They judge a single prompt in isolation and they forget the wider session. A capable attacker spreads the payload across many turns so each fragment looks harmless on its own. This guide builds the missing layer. It treats prompt injection as a detection problem and it catches the attack in the SIEM where your team already correlates events across time. Each part below ships with a working artifact you can lift straight into your own stack.

Quick Facts#

Threat: Prompt injection (OWASP LLM01) Detection surface: LLM gateway telemetry in the SIEM Layers: Regex plus Sigma plus a one class model Machine learning: One Class SVM with an RBF kernel Research backing: Electronics journal May 2026 Reported precision: 0.971 Reported recall: 0.8 Stance: Defense in depth not a silver bullet

Why the App Layer Is Not Enough#

A language model reads instruction and data through one channel. When an attacker writes text that the model treats as a command the line between content and control disappears. That is why the OWASP project ranks prompt injection first and calls it the hardest class to fully prevent. A guardrail that scans one message can block the obvious payload. It cannot see that three innocent looking turns add up to a single attack. The SIEM was built for exactly that gap because correlating events across time and source is its core job. The fix is to turn every model interaction into a security event and then let the SIEM do what it already does well.

Log the Right Telemetry#

Detection starts with good telemetry and a raw transcript is not enough. You want structured fields that a rule and a model can both reason about. Place a gateway in front of every model your business exposes and emit one event per interaction. At minimum capture the session and the user and the input and output along with a few derived features that betray an attack. The schema below is the foundation for everything that follows.

{
  "timestamp": "2026-06-20T10:14:33Z",
  "session_id": "sess_8f21",
  "user_id": "u_4471",
  "source": "support-bot",
  "input": "...",
  "system_prompt_hash": "sha256:7d0e...",
  "tool_calls": [],
  "output": "...",
  "input_len": 412,
  "output_len": 1180,
  "encoded_blob_ratio": 0.0,
  "guardrail_flags": [],
  "provenance": "user"
}

The derived fields matter as much as the raw text. The two length fields expose sudden verbosity. The encoded blob ratio flags base64 and unicode tricks. The guardrail flags field carries any hit from your inline filter. The provenance field records whether the text came from the user or from a retrieved document which is the tell for indirect injection.

Signature Detection With Regex#

The fastest win is a signature layer for the patterns everyone already knows. Instruction override phrases are the classic tell. The expression below matches the whole family of ignore previous instructions attempts without pinning to one exact wording.

OVERRIDE = r"(?i)ignore\s+(all|the|your)?\s*(previous|prior|earlier|above|original|initial)\s+(instructions|prompts|rules|context|constraints|guidelines|directions)"

Pair that with a keyword set for the well known jailbreak personas and a separate pattern for role reassignment and system prompt extraction.

JAILBREAK = r"(?i)(do anything now|\bDAN\b|developer mode|god mode|unrestricted mode|jailbreak)"
ROLE      = r"(?i)(you are now|your new (primary )?goal is|repeat the (text|system prompt) above)"

Run these against the input field on ingest and write the result into the guardrail flags field. A signature layer is cheap and precise but it only catches what you already named. That is why it is the first net and never the only one.

A Sigma Rule for the Gateway#

Signatures belong in version control as detection content and not as scattered scripts. Express them as a Sigma rule so one definition compiles to Elastic and Splunk and Sentinel through sigma-cli. The rule below fires when an override phrase or a jailbreak keyword shows up in gateway input.

title: LLM Prompt Injection Override Attempt
status: experimental
description: Detects instruction override and jailbreak phrases in LLM gateway input
logsource:
  product: llm_gateway
  service: prompt
detection:
  override:
    input|re: '(?i)ignore (all|the|your)? ?(previous|prior|above) (instructions|rules|context)'
  jailbreak:
    input|contains:
      - 'developer mode'
      - 'do anything now'
      - 'god mode'
  condition: override or jailbreak
fields:
  - session_id
  - user_id
  - input
level: high
tags:
  - owasp.llm01

Because the logic lives in Sigma you write it once and convert it for whatever SIEM you run. Keep the rule in a git repository and test it in your pipeline before it ever reaches production.

Catch the Unknown With One Class SVM#

Signatures miss the novel attack by definition. The answer is an anomaly net trained only on clean traffic. A one class model needs no labeled attacks. It learns the shape of normal from benign interactions and flags whatever falls outside that shape. The research this guide draws on trained such a model on 1200 benign interactions. Here is the same approach in scikit-learn.

from sklearn.svm import OneClassSVM
from sklearn.preprocessing import StandardScaler

# Features pulled from benign gateway telemetry
# input_len output_len encoded_blob_ratio token_entropy override_hits
X_benign = load_benign_features()          # shape (1200, 5)

scaler = StandardScaler().fit(X_benign)
X = scaler.transform(X_benign)

model = OneClassSVM(kernel="rbf", gamma="scale", nu=0.05)
model.fit(X)

def score(event):
    feats = scaler.transform([extract_features(event)])
    return model.predict(feats)[0]         # -1 means anomaly

Feed the model the derived features from your telemetry rather than the raw text. Retrain it on a fresh benign window on a schedule because a baseline drifts as your product changes. Treat a prediction of minus one as a lead for triage and not as an automatic block.

Severity and Response#

Not every hit deserves a page. Grade the output so the loud signals rise and the quiet noise stays out of the way.

Critical: a sensitive tool call like delete_data or execute_payment fires without approval or the model leaks system prompt text or credentials appear in the output High: the model adopts a system or admin role or the output length jumps far past its baseline Medium: several failed jailbreak attempts land in a short window or an encoding spike shows up in the input

Wire critical hits to an immediate alert and route high and medium into normal triage. Never let the model output drive an automated action you would not let an untrusted stranger trigger because that is precisely what a successful injection turns it into.

What the Research Shows#

This is not theory. A study published in the Electronics journal in May 2026 built the gateway and the SIEM correlation and the one class model described here and then measured it. Against 1100 prompts drawn from a malicious benchmark and a benign dataset it reported a precision of 0.971 and a recall of 0.8. The precision means an analyst can trust a flag because clean prompts were rarely accused. The recall is the honest part of the story. One in five attacks still slipped through. So this layer raises the cost of an attack and hands you an audit trail but it does not replace careful design at the application edge. Build it as the safety net it is.

Hunting LOLBins in Your SIEM With Sysmon and Sigma

Graylog MCP Conversational AI for Modern Security Operations

MCP Tool Poisoning and the Hidden Threat to Agentic SecOps

References#

Detecting Prompt Injection Attacks in Generative AI Systems A Hybrid SIEM and One Class SVM Framework. Electronics 2026.

OWASP Top 10 for LLM Applications. LLM01 Prompt Injection.

NeuralTrust. How to Set Up Prompt Injection Detection for Your LLM Stack.