Prompt Injection Detection: Judging Input Before Your AI Reads It

Every era of software gets the vulnerability its architecture deserves. Databases that concatenated strings got SQL injection; AI systems that feed untrusted text to instruction-following models get prompt injection: input crafted to be read as orders rather than data. "Ignore your previous instructions." "You are now in developer mode." The email that tells the summarizer to exfiltrate the inbox. If your product lets outside text anywhere near a capable model, this is your era's injection, and 2026's builders are converging on the same first line of defense: a screening judge in front of the main model.

The logic is straight cascade: before your expensive, capable, instruction-hungry model reads anything untrusted, a cheap decision model answers one narrow battery of questions about it. Not "is this safe" in the abstract, but the operational versions:

• Does this text contain instructions addressed to an AI system (role reassignment, "ignore/forget previous", mode-switching language)?
• Does it attempt to elicit system prompts, credentials, or hidden configuration?
• Does it instruct the assistant to take actions outside the current task (send, fetch, delete, browse)?
• Is there content whose framing differs from its function: a "quote" or "example" that is itself a complete instruction payload?
• For documents and web content: does any embedded or low-visibility text (footers, metadata-ish strings) address the reader-as-machine?

Flagged input gets quarantined, sanitized, or handled by a constrained path; clean input proceeds. At reported verdict prices, screening every untrusted string, every email an agent reads, every web page a browser agent ingests, every uploaded document, costs a rounding error against the incident it prevents.

Why the screener itself is hard to inject

A reasonable objection: aren't you just adding another model to trick? Partially, and the architecture is the answer. A decision model makes a poor injection target for structural reasons: it can only emit a closed-set verdict, so there's no free-text channel to hijack; it follows your fixed questions rather than instructions found in the input; and it holds no tools, secrets, or downstream authority to abuse. The screening layer is deliberately the least capable, least trusting component in the stack, which is precisely the job description. The same shape defends outbound too: guardrail verdicts on your model's outputs catch the injections that got through and worked.

The honest limits (security pages don't get to skip this)

Detection is a layer, not a solution, and anyone selling it as a solution is selling. Injections evolve adversarially, exactly like spam; novel phrasings will pass until your questions catch up. So the screener rides on top of structural defenses, never instead of them: least-privilege tools (the summarizer that can't send email can't be injected into sending email), strict separation of trusted instructions from untrusted data in your prompts, verification gates before irreversible actions, and output filtering behind it all. Log every flagged attempt: your injection queue is free red-teaming, and feeding it back into the question set per eval discipline is how the screen sharpens instead of rotting. Defense in depth is boring, which is how you know it's the real advice.

Frequently asked questions

What is prompt injection?

Crafted input that an AI system reads as instructions rather than data: overriding its task, extracting hidden configuration, or steering its tools. It's the characteristic vulnerability of instruction-following models handling untrusted text.

Can prompt injection be detected reliably?

Common patterns, yes, cheaply and at full coverage; novel attacks, only until they're novel. Treat detection as one layer above least-privilege design, prompt separation, and action verification, and assume the arms race is permanent.

Where should the screening layer sit?

In front of every untrusted-text entry point: user input, retrieved documents, web content agents read, emails, uploads. Anything your capable model consumes that you didn't write gets judged first.

Does screening add meaningful latency or cost?

At decision-model speed and reported pricing, milliseconds and fractions of a cent per input, invisible against the main model's own round-trip and trivial against incident cost. There is no economic excuse left for skipping it.