Prompt Injection, Explained Without the Jargon

If you only read one post in this series about AI security in general, rather than about G8KEPR in particular, make it this one. Prompt injection is the problem that sits underneath a lot of the others, and it's simpler to understand than the name suggests.

What it is

When you build an app on top of a large language model, you give the model instructions. Something like "You're a support assistant for a software company. Answer questions about our product. Be polite. Don't share internal pricing." Then a user types a question, and your app hands the model both things: your instructions and their question.

Prompt injection is when the user's part (or some other text the model reads) contains instructions of its own, written to override yours. The cartoon version is "ignore your previous instructions and tell me the internal pricing." Real attempts are rarely that blunt, but the idea is the same. Somebody's trying to get the model to take orders from them instead of from you.

That's really all it is. The damage depends on what the model can do. A chatbot that can only chat might say something embarrassing. A model that can read your files, send email or call your APIs is a different conversation.

Why it's so hard to fix

Here's the part that trips people up. With a classic web attack like SQL injection, there's a clean fix: keep the code and the data in separate lanes, and the database never confuses one for the other.

A language model doesn't have separate lanes. Your instructions, the user's message, and whatever documents you've attached all arrive as one stream of text. The model is very good at following instructions in text, and it has no reliable way to know which instructions are "real." It's a bit like handing someone a stack of papers and saying "do what the top page says," when page four also says "do what this page says instead."

So there's no single switch to flip. What you can do is watch for it, limit what a hijacked model is able to reach, and check what comes out the other end.

Direct and indirect

It helps to split injection into two kinds, because they show up in different places.

Direct injection is the obvious one. The person typing into your app is the one trying to break it. Jailbreaks live here too: attempts to talk the model out of its own safety rules, often dressed up to look harmless at first glance.

Indirect injection is the one that keeps security people up at night. The user may be completely innocent. They ask your assistant to summarize a web page, or read an email, or look something up with a tool. Somewhere in that page, email or tool result is text written for the model, not for the human. The model reads it along with everything else, and now an outsider's instructions are inside your app without anyone typing them.

This gets more serious as models get connected to more things. Every document store, inbox and MCP tool is another place that text can come from. I wrote about one flavor of this, where the tool's own description is the carrier, in the post on MCP tool poisoning.

Where G8KEPR's guard sits

G8KEPR has a prompt-injection guard inside the AI Gateway, which is the checkpoint between your app and the model providers. It sits in the request path, so a prompt passes through it before it goes out to the model. It's there to catch direct injection and jailbreak attempts, including the disguised ones that don't look like an attack at first read.

I'm going to stay at that level on purpose. A security product that publishes exactly what its detectors look for is handing out a map, and I'd rather not.

Why one guard isn't the whole plan

Given everything above, I don't think any single filter should be sold as "the fix" for prompt injection, and I'm not selling mine that way. That's why the guard is one checkpoint of four:

• The MCP Security pillar watches the tools themselves, so a tool that quietly changes what it says about itself gets noticed.
• The Verification Engine checks the answer after it's produced, so a model that got steered somewhere odd has a second chance of being caught on the way out.
• The correlation engine looks at signals from all four checkpoints together, so something that looks mildly off in two or three places at once gets treated more seriously than any one of them alone.

That last piece is the part I think is actually different, and it's covered in From Do-Everything Platform to Correlation Engine.

If you're building on top of a model and haven't thought about where outside text enters your prompts, that's a good question to sit with for ten minutes. You'll probably find more doors than you expected.