Skip to main content

Foundations

What is prompt injection?

A language model can’t reliably tell your instructions apart from instructions hidden in the content it’s reading — a webpage, a document, a tool result. What prompt injection actually is, why it can’t be fully solved by a smarter model, and what limits the damage when it happens.

All explainers · Last reviewed:

Two forms: direct and indirect

Direct injection is someone typing instructions straight into the chat trying to override the system’s intended behavior — asking the model to ignore its instructions, reveal hidden configuration, or act outside its intended scope. Indirect injection is the more consequential form: instructions planted in content the model reads on your behalf — a webpage, an email, a file, an API response — that the model was never meant to treat as commands but has no reliable way to distinguish from them.

Why a smarter model doesn’t fix this by itself

The problem isn’t that models are insufficiently intelligent — it’s architectural. Everything a model sees, whether it’s your request or text fetched from an untrusted source, becomes the same kind of token sequence once it enters the context window. There’s no separate, tamper-proof channel for "trusted instructions" versus "content to read." A more capable model can get better at recognizing common injection phrasing, but a sufficiently disguised instruction — split across text, phrased indirectly, hidden in formatting — can still slip through, because the underlying architecture has no hard boundary to enforce.

The risk grows sharply once a model can call tools

A chatbot that only produces text limits injection to bad or misleading output — annoying, but contained. Once a model can call tools (see how tool calling works) — sending an email, running a command, modifying a file — a successful injection can turn into an unwanted real-world action, not just a bad sentence. This is why systems that combine web browsing or document reading with tool access carry meaningfully more injection risk than a plain chatbot.

Filtering and scoping reduce the risk; neither removes it

Scanning fetched content for known injection patterns catches some attempts, but any fixed pattern list can be evaded by phrasing the instruction differently — this is a filter, not a guarantee. What reduces actual damage more reliably is limiting what a model is allowed to do regardless of what it was told: scoping tool access narrowly, requiring approval before a destructive or external-facing action, and never granting a model standing permissions wider than the specific task in front of it.

The content a model reads is untrusted input, not a neutral fact source

Any system that lets a model read external content — a search result, a scraped page, a document a user uploaded — is exposing it to instructions it didn’t ask for. The practical implication is treating that content the way you’d treat unvalidated user input in any other software: assume it can contain something adversarial, and design the surrounding system so that a successful injection has limited reach rather than assuming injection won’t happen.

Questions people ask

Can prompt injection be fully prevented?
No, not with current model architectures. There’s no built-in, tamper-proof separation between a user’s instructions and text a model reads from elsewhere, so filtering and scoping reduce risk and limit damage but can’t guarantee prevention.
Is prompt injection the same as jailbreaking?
They overlap but aren’t identical. Jailbreaking usually means a user directly trying to get a model to bypass its own guidelines. Prompt injection more often refers to instructions hidden in content the model reads on the user’s behalf, without the user’s knowledge.
Does prompt injection matter for a chatbot that can’t use tools?
It’s a smaller risk — a successful injection can produce a misleading or manipulated response, but it can’t take an action beyond generating text. The risk grows substantially once a model can call tools that do something outside the conversation.
Is scanning content for injection patterns enough protection?
It catches known, recognizable attempts, but any fixed pattern list can be evaded by rephrasing. Real protection also comes from limiting what a model is allowed to do — narrow tool scope and required approval for consequential actions — not from detection alone.

Try it rather than read about it

ClawAI’s research service scans fetched web content for known prompt-injection patterns and redacts secret-looking tokens before that content reaches a model — logging what it detects rather than silently blocking, since no fixed pattern list can catch every attempt. That detection layer is one part of a defense that also depends on scoping what tools a model can call in the first place.