Direct injection: the user is the attacker

Lesson 2 of 5 in Prompt Injection: The Vulnerability With No Patch.

In direct injection the hostile text arrives through the front door: the person typing at the agent is the adversary. This is the variant everyone demos, and — for most production agents — the less dangerous of the two, for a reason worth being precise about.

If a user talks your consumer chatbot into ignoring its persona, the user has mostly harmed themselves. Direct injection becomes a real security event exactly when the agent holds authority the user does not: it reads a shared knowledge base, it acts on other tenants’ records, it wields a service account with production credentials. That is the classic confused deputy shape, and it is why “the user can jailbreak it” is a weak finding while “the user can make it call an internal tool on someone else’s data” is a serious one.

Role-play and persona coercion

The attacker asks the model to be something else: a fictional character with no rules, a debugging mode, a “developer” voice, a translation of the forbidden thing into a story. Mechanically these work because the model is a general-purpose text continuation engine and your persona instruction is just one more piece of framing competing with the attacker’s.

Defender’s read: never treat persona compliance as a security property. The question is only what tools are attached to that persona.

Authority and process framing

Instead of fighting the instructions, the attacker impersonates legitimate authority over them: text presenting itself as a compliance check, an administrator override, a policy update, an urgent escalation with a deadline, or a mandate to retry if the first attempt is refused. Radware’s ShadowLeak write-up (18 September 2025) documented exactly this stack — authority claims, a fake “compliance validation system”, urgency, retry mandates — as the way the injection defeated refusal behaviour.

Defender’s read: an agent has no way to authenticate a claim of authority made in text. Authority must arrive out of band, through the runtime — an identity, a signed policy, a permission — never as a sentence.

Obfuscation and encoding

Base64, homoglyphs, unusual languages, split-across-turns payloads, text embedded in an image the model can read. The purpose is not to fool the model — it will happily decode — but to fool your filter, which is looking at surface strings.

Defender’s read: this is the structural reason input classifiers plateau. Your detector sees a different representation than the model’s effective instruction, and the attacker chooses the representation.

Payload splitting and context stuffing

Long conversations dilute the system prompt: instructions from twenty turns ago compete with a wall of recent attacker text, and behaviour drifts. Splitting an attack across turns also defeats per-message classification, since no single message looks hostile.

Defender’s read: session length is a security parameter. Fresh context per task, bounded turn budgets, and re-asserting critical constraints are cheap; they also happen to improve reliability.

Notice what every tab has in common: the defender’s read never says “add a better instruction.” Filters catch the attacks that look like the attacks you have already seen — that is genuinely useful against opportunistic and automated probing, and it is why every serious deployment runs them. But a classifier is a fixed function facing an adversary with unlimited retries, no rate limit on creativity, and full knowledge that a near-miss costs them nothing. Against that, coverage measured on a benchmark is a rate, not a bound.

So the useful triage question for a direct-injection finding is not can the model be talked out of its instructions — assume yes — but what does the model have permission to do once it has been. Walk that logic.

Triage a direct-injection finding

Interactive decision tree — outcomes:

  • Confused deputy — treat as high severity

    The user borrows the agent’s privileges to do what they could not do themselves. Fix at the identity layer: the agent should act as the user wherever possible, and any tool needing more privilege belongs behind scoping and an approval gate. Prompt hardening is not a remediation here.

  • Cross-boundary read — scope the retrieval, not the prompt

    Coercion turns into data disclosure the moment privileged reads are echoed back. Enforce the tenant/permission filter in the retrieval layer so the model physically cannot receive what this user may not see. A model that never holds the secret cannot be argued into revealing it.

  • Binding statements — constrain the output path

    Air Canada was held liable in February 2024 for advice its chatbot gave a customer: a coerced or simply wrong statement can create obligations. Constrain what the agent may assert — template or verify prices, terms, and commitments through a system of record rather than trusting generated text.

  • Low severity — log it, do not chase it

    A user reshaping their own private assistant is mostly a terms-of-service matter. Keep the traces and the detection signal (repeated attempts are reconnaissance worth alerting on), and spend your engineering budget on the indirect variant in the next lesson.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.