Prompt Injection Detection Is Moving Into the LLM Firewall Layer

The old model of prompt injection defense is already obsolete: if you only inspect the prompt after it reaches the model, you are checking the lock after the door has been kicked in. The real control point is one layer up, in the LLM gateway or firewall, where you can inspect user input, retrieved context, and tool calls as one security event.

That shift matters because you are no longer just chatting with a model. You are wiring copilots into Gmail, Jira, Slack, ServiceNow, SharePoint, and internal APIs. A malicious instruction can arrive through an email thread, a ticket comment, or a poisoned document and still end up steering an agent. That is not “model safety.” It is traffic inspection for AI workflows, and the usual “we have a policy” answer is theater with a badge.

Prompt injection is a gateway problem, not a model problem

Prompt injection used to look like a jailbreak demo. Now it looks like abuse of a trusted intermediary.

If an agent can read a ticket, summarize a mailbox, and call a password reset API, the attack surface is the whole path, not the final prompt string. That is why tools like Lakera, Prompt Security, and Cloudflare’s AI Gateway are moving to inspect prompts before they hit the model. The useful question is not “Did the model obey?” It is “Should this instruction have been allowed into the workflow at all?”

The tool call is where the damage happens

A malicious instruction buried in a PDF is annoying. A malicious instruction that convinces an agent to call a Jira API, export a CRM record, or trigger a Slack webhook is an incident.

This is where identity shows up, because the real target is the agent’s token, session, or delegated API scope. We have seen this movie before: exposed interfaces and overbroad credentials do most of the damage, not exotic malware. Same story, newer costume. If your agent can reach production data with broad OAuth scopes, you have already made the attacker’s job easier than it should be.

Retrieved context can be poisoned before the model sees it

RAG creates a supply-chain problem inside your own app. If a poisoned Confluence page, SharePoint doc, or support article gets retrieved into context, the model may treat attacker-controlled text as trusted instruction.

That is the AI version of a compromised build pipeline, except the pipeline is your retrieval layer. SolarWinds taught everyone the hard way that trusted distribution is excellent camouflage. The non-obvious part: filtering only the user prompt misses the attack if the malicious instruction lives in retrieved content, not in the chat box. If your threat model does not include your own knowledge base, it is not a threat model.

Boring controls still win: least privilege, segmentation, logs

The best LLM firewall is not magic. It is boring security applied to AI plumbing: narrow tool permissions, separate read-only from write-capable agents, log every retrieval and tool invocation, and segment the systems the model can touch.

That is how you make prompt injection less profitable. If you do not red-team your own AI integrations, you will eventually learn the hard way, usually from a ticket that “just asked for a summary” and ended with data exfiltration. Compliance will not save you here. Neither will a dashboard full of green checkmarks. Audit logs, scoped tokens, and explicit allowlists will.

Bottom line

Treat prompt injection as an application-layer abuse problem, not a model quirk. Put inspection and policy enforcement at the gateway, not just in the prompt. Scope every agent token to the minimum needed, split read and write paths, and log retrievals and tool calls with enough detail to reconstruct what happened. Then red-team the full workflow: user input, retrieved context, and downstream actions. If you only test the chat box, you are missing the part that actually gets you burned.