Threat Intelligence advanced

Detecting Prompt Injection in Production: Watch the Trifecta Close, Not the Prompt

Prompt injection is OWASP's #1 LLM risk and you can't filter it out. Stop detecting the prompt — detect the lethal trifecta closing in one session.

May 5, 2026 · 17 min read · Gowthamaraj Rajendran

Prompt injection has been the number one risk on the OWASP Top 10 for LLM Applications for two editions running — LLM01, both in 2023 and again in 2025 [1]. It has held that spot for the least satisfying reason in security: it is the one vulnerability class you cannot patch. There is no version of a language model that reliably tells the difference between instructions it should follow and data it should merely read, because to the model they are the same tokens. Every mitigation is probabilistic. None is a fix.

So here is the thing most detection teams get wrong when they finally turn their attention to AI: they try to detect the prompt. They stand up a classifier, wire it to fire on “ignore previous instructions,” and call it coverage. That is the wrong target, and this post is about the right one.

You will not catch the injection by reading inputs. You catch it by watching what the compromised system does — specifically, by watching the one sequence of actions the attacker needs and cannot avoid. That sequence has a name, and it is observable.

Detecting the Prompt Is a Losing Bet

Start by being honest about the input layer, because that is where every team’s first instinct goes and it is where the effort gets stranded.

A prompt-injection classifier is a good preventive control. It is a bad detection strategy. Those are different jobs, and conflating them is the mistake.

The evidence is not close. A 2025 empirical study of production guardrail systems found that obfuscated or paraphrased attacks bypass more than 70% of the time across nearly every guardrail tested, with the worst performer sitting around an 88% attack success rate [2]. And that is before the adversary gets creative with encoding: hiding instructions in zero-width Unicode characters, homoglyphs, or emoji variation selectors has been demonstrated to slip past top guardrails at rates approaching 100% while remaining perfectly legible to the model [3]. The payload your regex is looking for — “ignore previous instructions” — is the version an attacker uses in a screenshot for a conference talk, not the version they use against you.

Rule-based filters fail on paraphrase. Classifiers do better on paraphrase but false-positive on the entire class of legitimate traffic that discusses injection — your own security team asking the bot about prompt injection trips the wire. And both live at the one layer where the attacker has the most freedom to mutate their input and the most channels to smuggle it through.

This is exactly the shape of the coverage problem I laid out in The Detection Funnel: a control that looks green on the dashboard while the technique walks past it. A guardrail reporting “1,400 injection attempts blocked this week” is telling you about the attempts that used the obvious phrasing. It is silent about the ones that did not, which are the ones that matter.

None of this means rip out the guardrail. Defense in depth is the right model here: keep the preventive filter as the first layer — it cheaply stops the low-effort, high-volume noise — and build a detection layer underneath it to catch the determined attacker who bypasses it. The mistake is treating layer one as if it were the whole stack. Prevention at the input layer is worth doing. Detection at the input layer is not, because you are detecting the one thing the attacker can trivially change.

So move down a layer, to the thing they cannot change.

The Lethal Trifecta Is the Detectable Unit

In June 2025, Simon Willison — who coined the term “prompt injection” back in 2022 — gave the dangerous configuration a sharper name: the lethal trifecta [4]. An AI system is exploitable for data theft when it combines three capabilities in one session:

Access to private data — the model can read something an attacker wants.
Exposure to untrusted content — the model processes input an attacker can influence.
A way to communicate externally — the model can send data back out.

Hold any two and the system is safe. Hold all three and an attacker who controls the untrusted content can instruct the model to read your private data and ship it out — no exploit code, no CVE, just a sentence in a document the model was always going to read.

This is the reframe that turns an unsolvable problem into a tractable one. You cannot see the prompt injection. But the trifecta is not a prompt — it is a sequence of actions, and actions are logged. Untrusted content entering the context is an event. A sensitive read is an event. An outbound call is an event. The attack is invisible; the trifecta closing is not.

Look at the Slack AI disclosure from PromptArmor as the canonical worked example [5]. An attacker placed a malicious instruction in a public Slack channel. When a victim later asked Slack AI a question, the model — pulling context from both public and private channels — followed the planted instruction, read an API key the victim had put in a private channel, and rendered a “click here” link that exfiltrated the key as a URL parameter. Trace the three legs: untrusted content (public channel), private data (the key in the private channel), external communication (the crafted link). All three, one session. That is the trifecta, and every leg of it generated a log line even though the injection itself was just plain English.

The same skeleton shows up everywhere once you look for it. EchoLeak (CVE-2025-32711), the zero-click Microsoft 365 Copilot exfiltration, was a trifecta closing off a single crafted email [6]. CurXecute (CVE-2025-54135, CVSS 9.8) was an injection hidden in a repository README that Cursor’s assistant read on project open, escalating to command execution on the developer’s machine [7]. And in March 2026, Palo Alto’s Unit 42 published the first documented set of in-the-wild indirect prompt injections against live AI agents — twelve real cases, including a payload built to bypass a production ad-review model [8]. This is no longer a research demo. It is operational, and it has a consistent structure you can detect.

The LLM Gateway Is Your New Log Source

If the trifecta is what you detect, the LLM gateway is where you see it.

Most AI applications already route their model traffic through a gateway — Portkey, Kong AI Gateway, Cloudflare AI Gateway, TrueFoundry, LiteLLM — for cost control, routing, and caching. That gateway sits at the exact chokepoint a detection engineer wants: every prompt, every retrieved context chunk, every tool call, and every model response passes through it. The security question is whether you are capturing that traffic as structured telemetry or letting it evaporate into a latency dashboard.

The standard to capture it against now exists. OpenTelemetry’s GenAI semantic conventions define a common schema for AI operations — gen_ai.input.messages, gen_ai.output.messages, gen_ai.system_instructions, and execute_tool spans for every tool invocation, all as structured span attributes [9]. When your gateway emits OTel GenAI spans, the trifecta stops being a story you reconstruct after an incident and becomes three fields you can correlate in real time: what content entered the context, what the model called, and what came back.

Here is how the industry actually wires this today, because I want to be concrete rather than aspirational about the maturity:

The SIEM path is real and shipping. Teams pipe structured gateway logs into Splunk, Sentinel, Elastic, and QRadar and correlate LLM activity with the rest of their signals. Splunk ships a MITRE ATLAS AI Threat Detection app that covers prompt injection, jailbreak, and exfiltration out of the box [10]. A published hybrid framework — gateway telemetry into Elastic SIEM, expert rules plus a one-class model trained on benign traffic — reported 0.971 precision against real attack samples [11]. Sigma compiles one rule to all of those backends, so this is not a rip-and-replace.
But most instrumentation is for ops, not security. The large majority of LLM observability deployments today track tokens, cost, latency, and answer quality. The security overlay — treating the gateway as a detection source, not a billing meter — is the part almost nobody has built, which is the same adoption gap I keep hitting across the non-human identity blind spot: the capability exists, the deployment does not.
And there is a real tension to name. The privacy-preserving way to log AI traffic is to redact PII and secrets from prompts and responses before they hit your store. But the content you redact is often the content you would detect on. If your gateway strips the exfiltrated key before logging, your detection rule never sees it. Resolving that — log “policy evidence” and structural metadata richly, gate raw content behind strict access controls — is a design decision you have to make deliberately, not discover during an incident.

The gateway is the highest-value AI log source you are probably not collecting for security. Fix that first. Everything below depends on it.

Three Signals, Joined by a Threat Model

A single trifecta leg is not an alert. Untrusted content enters an AI’s context constantly — that is what RAG is. Sensitive reads are the job. Outbound calls are the feature. Any one of them alone is noise. The detection is the join: the same session, on the same principal, closing all three legs in sequence.

That is the general model. But a generic “all three legs” rule fired across every AI system you run will bury you in false positives, because a customer-support RAG bot and an autonomous coding agent have completely different normal behavior. This is the part that matters, and it is where your judgment does the work: you model how the specific system is supposed to operate, derive its trifecta exposure from that, and write the detection against that model. More signals give you more ways to cut false positives, not fewer — every additional dimension you can baseline is another way to separate the real trifecta from the benign one.

Concretely, for a given AI system, define:

What untrusted content looks like for it. For a support bot, an inbound customer message and a retrieved knowledge-base article. For a coding agent, a repo README, an issue body, a fetched web page. Tag the source-trust of everything entering the context. Content the attacker can influence is untrusted, full stop — including your own “trusted” wiki if outsiders can write to it.
What its sensitive reads are. The data domains this system has no routine business touching in the same breath as untrusted input. Customer records, secret stores, other users’ private data, internal search over confidential corpora.
What egress it actually has. Every channel that can move bytes past the trust boundary: an HTTP tool, an email send, a webhook, and the sneaky one — rendering a Markdown image or link, where the data rides out in the URL. That last one is how both Slack AI and EchoLeak exfiltrated, and teams forget it is an egress channel because it looks like formatting.

With those three modeled per system, the correlation becomes precise instead of paranoid. You are no longer asking “did an injection happen.” You are asking “did this principal, in this session, ingest attacker-influenceable content, then read a sensitive domain, then reach an egress channel — a sequence its normal workflow never produces.” That is a question the gateway telemetry can answer, and it is the same per-principal, per-session baselining discipline I argued for with agents in Detect the Action, Not the Prompt — here applied to the injection technique specifically, and to non-agentic systems like RAG chatbots and Copilots that the agent framing did not cover.

One Rule, Built to Be Instantiated

Here is the trifecta correlation as a Sigma rule. Read it as a template you tune per system, not a drop-in — the whole point of the previous section is that the source-trust tags, the sensitive tools, and the egress tools are specific to the AI system you are protecting.

# Detection rationale: prompt injection is invisible at the input layer, but the
# lethal trifecta it needs is not. This fires when ONE session on ONE AI principal
# closes all three legs: (1) attacker-influenceable content enters the model
# context, (2) a sensitive data source is read, (3) an egress-capable tool is
# invoked. It keys on the session-level JOIN across gateway telemetry, never on a
# prompt string — so paraphrase, encoding tricks, and emoji smuggling do not evade
# it. The attacker can mutate the injection freely; they cannot avoid the actions.
#
# Threat-model note: untrusted_context, sensitive_read, and egress MUST be tuned to
# the specific system. A RAG support bot and a coding agent have different trifecta
# surfaces. This is a pattern to instantiate per system, not a universal rule.
title: Prompt Injection Trifecta Closing in a Single AI Session
status: experimental
logsource:
  product: genai
  service: gateway   # OpenTelemetry GenAI spans / LLM gateway audit log
detection:
  untrusted_context:
    # content the attacker can influence, pulled into the prompt context
    gen_ai.context.source_trust: 'untrusted'   # RAG doc, inbound msg, README, web page
  sensitive_read:
    gen_ai.tool.name:
      - 'read_private_channel'
      - 'query_customer_records'
      - 'read_secret'
      - 'internal_confidential_search'
  egress:
    gen_ai.tool.name:
      - 'http_request'
      - 'send_email'
      - 'post_webhook'
      - 'render_markdown_image'   # data rides out in the URL — easy to overlook
  # Correlate the three legs within one session/principal. In deployment this is a
  # Sigma correlation rule (or a SIEM stats-by-session join), not a flat condition.
  condition: untrusted_context and sensitive_read and egress
  correlation_scope:
    group_by: [ 'gen_ai.session.id', 'gen_ai.agent.id' ]
    timespan: 15m
falsepositives:
  - Legitimate chains that summarize an external doc and email the result — baseline
    these per system and allowlist the known-good sequences
  - An agent whose normal envelope spans all three legs — that is not a false
    positive, it is an over-scoped agent; fix the architecture, do not tune it off
  - RAG over a corpus wrongly tagged untrusted — correct the source-trust labeling
level: high
tags:
  - attack.exfiltration
  - attack.ta0010
  - atlas.AML.T0051   # LLM Prompt Injection (MITRE ATLAS)

Prompt injection does not map cleanly onto MITRE ATT&CK — it lives in MITRE ATLAS, the adversarial-ML companion matrix, as AML.T0051. Tag it there so your AI detections roll up somewhere coherent instead of being wedged into an ATT&CK technique that does not fit.

One rule will not cover every system. That is the design, not a limitation: the value is the shape — a cross-signal join within a session, keyed on actions rather than strings — instantiated against each AI system’s own threat model.

The Bigger Ask: Make the Architecture Refuse to Close

Detection here is doing what detection always does when prevention is imperfect: catching what got through. But the trifecta hands you something most detection work does not — a clear prevention target, because the trifecta is an architecture property, not an attacker choice.

Willison’s own conclusion is that the fix is architectural, not a better prompt: do not build a system that combines untrusted input, private data, and an egress channel in one privileged session [4]. Break any one leg and the trifecta cannot close. Separate the component that reads untrusted content from the one that holds sensitive access. Strip egress from the agent that processes external documents. Require a human approval between an untrusted-context read and a privileged action. Each of these breaks the chain structurally, so no injection — however cleverly encoded — can complete the theft.

This is the same conclusion I reached about identity in The Kill Chain Defends Five Stages the Attacker Skips: prevention is where you win, and detection is what you build for the cases where prevention was imperfect or impossible. The reason detection still matters is that you will not always get to redesign the system — a vendor’s Copilot, a SaaS AI feature, a legacy agent someone shipped before anyone asked security. For those, the trifecta correlation is your net. But where you do control the architecture, the strongest detection is the one that makes an alert impossible because the trifecta can never form.

And that reframes your worst false positive. When the trifecta rule fires on a system whose normal behavior spans all three legs, that is not noise to tune away. That is the rule correctly identifying an AI system that is one well-worded document away from being an exfiltration tool. The alert is doing its job. The fix is not a suppression filter — it is a scoping conversation with whoever owns that system.

What to Do Monday

You will never win at the input layer. Stop measuring your AI security posture by how many prompts your guardrail blocked, and start measuring whether you could see a trifecta close.

Three moves, in order:

Turn the gateway into a security log source. Emit OpenTelemetry GenAI spans, capture source-trust, tool calls, and responses, and pipe them to your SIEM — with content access controlled, not redacted into uselessness. You cannot detect what you do not collect.
Threat-model each AI system’s trifecta. For every production AI, write down its untrusted inputs, its sensitive reads, and its egress channels. That document is your detection spec.
Correlate the trifecta per session, and treat un-tunable alerts as architecture bugs. Ship the join, then push the systems that legitimately span all three legs back toward a design where they cannot.

The prompt is the part the attacker controls, mutates, and hides. The actions are the part they cannot avoid and you already log. Point your detection at the actions, and the injection you were never going to read stops mattering — because you were never trying to catch the sentence. You were watching the trifecta close.

Resources

LLM01:2025 Prompt Injection — OWASP Top 10 for LLM Applications — OWASP GenAI Security Project, 2025 (prompt injection ranked #1 for the second consecutive edition).
Bypassing LLM Guardrails: An Empirical Analysis of Evasion Attacks — arXiv:2504.11168, 2025 (>70% bypass across nearly all tested guardrails; worst case ~88% attack success).
Outsmarting AI Guardrails with Invisible Characters and Adversarial Prompts — Mindgard, 2025 (zero-width, homoglyph, and emoji smuggling bypass top guardrails at rates approaching 100%).
The lethal trifecta for AI agents: private data, untrusted content, and external communication — Simon Willison, June 16 2025 (the three-capability configuration that enables data theft; fix is architectural).
Data Exfiltration from Slack AI via Indirect Prompt Injection — PromptArmor, August 2024 (public-channel injection reads a private-channel API key and exfiltrates it via a crafted link).
CVE-2025-32711 (EchoLeak) — NVD, 2025 (zero-click indirect prompt injection exfiltrating data from Microsoft 365 Copilot, CVSS 9.3).
CVE-2025-54135 (CurXecute) — NVD, 2025 (prompt injection in a repository README leads to remote code execution in Cursor IDE, CVSS 9.8).
Fooling AI Agents: Web-Based Indirect Prompt Injection Observed in the Wild — Palo Alto Networks Unit 42, March 3 2026 (twelve documented in-the-wild indirect prompt injections against live AI agents).
Semantic conventions for generative AI spans — OpenTelemetry (standardized gen_ai.* span attributes for prompts, responses, and tool calls).
MITRE ATLAS AI Threat Detection for Splunk — Splunkbase (detection content for prompt injection, jailbreak, and exfiltration against LLM telemetry).
Detecting Prompt Injection Attacks in Generative AI Systems: A Hybrid SIEM and One-Class SVM Framework — Electronics (MDPI), 2025 (gateway telemetry into Elastic SIEM plus a benign-trained model; 0.971 precision on real samples).