Web applications draw a hard line between code and data. Language models do not. A model receives one stream of text, and the developer's instructions sit in that stream beside the user's request, the documents it retrieved and the results of the tools it called. The TryHackMe input manipulation room builds the mental model for what follows from that: if the model cannot tell policy from content, then control has to live in the application that surrounds it.
This room is the input-side complement to the output-handling room. There, model output was the untrusted data. Here, the untrusted surface is everything the model reads, and the failure is not a crash or a leaked file but a change of intent: the model does the wrong thing while sounding entirely reasonable.
01 · Scope and authorisation
This companion documents the public TryHackMe Input Manipulation and Prompt Injection room, a standard AI-security learning room. It is an isolated, learner-controlled environment. I ran it in my own assigned session and confined everything below to that environment. I did not probe other hosts, and I have not published any flag, room answer, credential or reusable attack string. Where an exact value would matter, it appears as a placeholder or is described rather than reproduced.
The room maps to two OWASP Top 10 for LLM Applications 2025 entries: LLM01, Prompt Injection, and LLM07, System Prompt Leakage. It is defensive and educational. The flags are not the lesson; the separation of instructions from data is.
02 · Learning objectives
I set these objectives before starting and tested each one against the room:
- Explain why a language model cannot separate developer instructions from untrusted text.
- Identify the five layers that reach one model invocation.
- Describe system prompt leakage and why hiding the prompt is not the same as protecting it.
- Distinguish direct from indirect prompt injection, and say which is harder to defend.
- Explain why a filter cannot fully solve injection.
- Produce an instruction-layer inventory and a capability question for a real AI feature.
03 · Environment and evidence inventory
I treated the room like a real review. Before touching anything, I inventoried the components and asked, for each one, whether its text can carry an instruction.
| Layer | Source of text | Can it carry an instruction? |
|---|---|---|
| System policy | Developer definition | Yes, by design. |
| User input | The person using the app | Yes, directly. |
| Retrieved content | Documents, pages, records | Yes, indirectly. |
| Tool results | APIs, functions, feeds | Yes, indirectly. |
| Conversation history | Earlier turns and memory | Yes, and it persists. |
The finding that shaped the whole session was the fourth column. Every row answered yes. In a traditional application, only one of those inputs would be attacker-controlled and the others would be trusted code. In an LLM application, all five arrive as plain text at the same place, with no runtime marker that says which one is policy and which one is payload.
04 · The instruction layer model
The room frames prompt manipulation as an application risk rather than a flaw inside a model. That framing is the useful part. The model is doing its job: it predicts the next token, and text that looks like an instruction is followed whether that text came from the developer or a stranger. The vulnerability lives in the application that concatenates policy, input, retrieved content and tool output into one trusted blob and then acts on the result.
I described the room's demonstrations in the same terms everywhere below: a user-controlled conversation that shifts an assistant's intended behaviour, and a request that causes the same assistant to act on an instruction hidden in content it reads. Both are the same mechanism wearing different clothes. In one, the hostile text travels through the user; in the other, it travels through stored content the user never had to touch.
05 · Bounded validation: system prompt leakage
Goal: test whether the model will reveal its own configuration. Evidence: how the application assembles and protects the system policy. Hypothesis: if the policy is placed in the context as ordinary text, a request that reframes the policy as content to be summarised or explained will surface it.
The room shows the general pattern without requiring a copyable payload, and that is the right way to teach it. The model does not have a secret compartment for the system prompt; it is a line in the context, and questions that treat it as text tend to work: asking the model to restate its instructions, to summarise the rules it was given, or to treat its configuration as a user message and respond to it. What matters is the interpretation, not a specific string.
Why does this happen? Because "keep the following instructions secret" is itself an instruction, sitting in the same stream as the request that contradicts it. There is no privileged channel. The transferable engineering point is that system prompt leakage is an information-disclosure issue with a misleading name: the prompt is not a secret store, and anything that must not be disclosed should not be placed in the context at all. OWASP's LLM07 entry makes the same argument: do not treat the system prompt as a vault, and move sensitive data and access decisions into systems outside the model.
06 · Bounded validation: jailbreak framing
Goal: decide whether reframing the task changes which policy the model follows. Evidence: the room's own guardrail behaviour. Hypothesis: a request that switches persona, wraps the task in a story, or buries the real ask inside a benign one will be treated differently from the same ask stated plainly.
The room demonstrates this in a controlled way. The observation I recorded is the shape of the pattern rather than a payload: the model is optimised to be helpful and cooperative, so a prompt that reframes the situation can be read more favourably than a direct request for the same outcome. Jailbreak framing is a special case of the same root cause as injection. Developer policy and user text are one concatenated input, and the model may treat the most recent, most specific or most cooperative-sounding text as the operative instruction.
Failure mode: it is tempting to read a successful jailbreak as the model "deciding" to break its rules. That reading leads to the wrong fix, which is a better-worded rule. The better reading is that no rule in the context is enforced by anything, so the defence has to be a control the model cannot talk its way past.
07 · Bounded validation: direct injection
Goal: test whether user input can redirect the model's task. Evidence: the application's intended flow for the request. Hypothesis: if the user's text is concatenated with policy rather than separated from it, an instruction inside the user's text will be followed.
Direct injection is the simplest form: the hostile instruction is in the user's own message. The room treats it as the baseline case, and the lesson is about what the application allowed afterwards. A model that follows an injected instruction is only a problem if that instruction reaches something that matters: a tool call, a data read, a message sent on the user's behalf or a record changed. In the room, the demonstration is bounded and non-destructive, and the teaching point is the capability question that follows the injection, not the payload itself.
Why does this happen? The model has no mechanism for weighting a developer instruction above a user instruction. Both are text in one context. When a user writes "ignore the above and do this instead", the model is doing exactly what a next-token predictor does with that input; there is no reference monitor that says the earlier text outranks the later text. The transferable move is to stop asking the model to prefer the developer instruction and start treating every model-initiated action as a request that the application must independently authorise.
08 · Bounded validation: indirect injection through stored content
Goal: decide whether content the model reads can carry an instruction. Evidence: the room's second demonstration, where a benign-looking request causes the assistant to act on text stored in content it retrieves. Hypothesis: if retrieved content flows into the same context as policy and user input, text in that content can act as an instruction without the user ever writing it.
Indirect injection is the more dangerous of the two, because the attacker never has to be the user. The hostile instruction can live in a document, a web page, an email, a support ticket, a record or a tool result, and it fires when the model reads it. In the room, the demonstration is contained, and the value is the lesson: the assistant distinguished the user's innocent request from the hidden instruction in neither place, because both arrived as text.
Why does this matter more than direct injection? Because it breaks the assumption that the person asking is the person attacking. A user who asks an assistant to summarise a page did not write the instructions on that page. If the assistant treats everything it reads as equally authoritative, then every piece of content it touches becomes an attack surface, and the user becomes an unwitting delivery mechanism. The room makes this concrete, and it is the reason indirect injection is the case that forces architectural controls rather than clever filters.
09 · Why the chain works
Every failure in this room follows the same three-link chain. First, untrusted text carrying an instruction reaches the model's context. Second, the model follows it, because nothing in the model distinguishes policy from payload. Third, the application acts on the model's output without an independent check, so the injected intent becomes a real side effect.
The chain is why input manipulation composes with everything else. Injected text can drive a tool call, and a tool call can reach a sink; that links this page directly to the output-handling room, where the sink is the problem. It also links to the agent-security picture, where the model holds real authority: the more capability the model can reach, the more the chain can do. When you review an AI feature, review the chain, not the chat window.
10 · Common misconceptions and troubleshooting
- "The system prompt is secret." It is text in the context, and text can be surfaced. Do not put secrets there.
- "A stronger instruction fixes injection." It reduces some cases and never closes the class. Instructions are not enforcement.
- "Filters stop injection." Blocklists fall to encoding, paraphrase and novel phrasing. They belong in depth, not alone.
- "Only the user can attack the input." Indirect injection means content the agent reads can carry the instruction.
Troubleshooting a model's behaviour is mechanical once you have the model. Ask what text reached the context, which layer it came from, what capability was available afterwards and what the application did when the model acted. If a team cannot answer those four, the review is not finished. In the lab, every surprising response traced back to a missing answer to one of them.
11 · Defensive fixes and secure configuration
The room's real output is a set of design decisions, not a filter list. The honest starting point is that prompt injection cannot be fully removed while models follow natural-language instructions, so the controls move outward from the model to the system around it.
| Exposure | Durable control |
|---|---|
| System prompt treated as a secret store. | Keep secrets and access decisions out of the context entirely; never rely on the model to withhold them. |
| Model can reach high-impact tools. | Least privilege for tools, and an independent authorisation check on every side effect. |
| Untrusted content enters the context unlabelled. | Wrap retrieved content as clearly delimited data, and treat delimiters as hygiene, not as a boundary. |
| No visibility into model intent. | Log the instruction layers and the actions taken, and separate the model's request from the system's decision. |
| High-impact actions run autonomously. | Keep a human in the loop for irreversible or sensitive operations. |
| Guardrails assumed to be complete. | Use input and output guardrails as defence in depth, and test them adversarially rather than trusting them. |
The ordering matters. Delimiters and guardrails are cheap and worth having, but they are mitigations. The controls that hold under pressure are least privilege, independent authorisation and human approval, because they do not depend on the model correctly perceiving which text was an instruction.
12 · Detection and logs
Detection for input manipulation is a review discipline before it is an alert. Log the instruction layers that reached each invocation and the actions that followed, so a reviewer can see which text preceded a surprising tool call. A record that separates what the model requested from what the system allowed is worth more than a transcript of the chat. Pair that with periodic adversarial testing of the boundary, using the same instruction-layer model the room teaches, and re-test after every change to the prompt, the tools or the retrieval sources.
When something does fire, trace the full chain: which text reached the context, which layer it came from, what the model asked to do and whether the application authorised it. If any link is not observable, add the telemetry. The incident question is the same as the design question: where did text cross from content into instruction, and what capability did that unlock?
For mapping, the failure classes in this room correspond to common enumerations: CWE-1427 for improper neutralisation of instructions in a prompt, CWE-74 for injection when injected text reaches an interpreter, CWE-200 for exposure of the system prompt or configuration, and CWE-441 for the confused-deputy pattern that indirect injection creates when the model acts with the user's authority on an attacker's instruction.
13 · Memory aids and practice checklist
Memory aid: layers, then capability. First name every text source that reaches the context. Then, for each action the model can take, ask whether it is authorised independently of the model's intent. The layers tell you where an instruction can come from; the capability tells you what it can do.
- List the five instruction layers and mark which ones are attacker-influenceable.
- Confirm no secret and no access decision lives only in the system prompt.
- Confirm every side effect has an authorisation check outside the model.
- Delimit retrieved content and tool output, and test whether the delimiter can be broken.
- Test direct and indirect injection as separate cases.
- Test the denial paths, not only the happy path.
14 · What the room teaches
Every lesson here reduces to one sentence: a language model generates text, and the application decides what that text is allowed to do. That is the input-side twin of the output-handling lesson, and together they describe the full trust boundary of an LLM application: what the model reads, and what its output is allowed to reach. The discipline transfers to any system where a model consumes untrusted text and can act on it, including agents with tools, assistants that read documents and pipelines that summarise third-party content. For the output side of the same boundary, see the companion note on treating model output as data. For a live case of an agent whose own confinement failed, read the field note on the sandbox that disabled itself.
Frequently asked questions
What is prompt injection in an LLM application?
It is the class of failures that arises because a language model cannot reliably separate developer instructions from user text, retrieved content or tool output. Any text that reaches the context window can act as an instruction.
What is the difference between direct and indirect prompt injection?
Direct injection places the hostile instruction in the user's own input. Indirect injection hides it in content the application later reads, such as a document, web page, email, record or tool result, so the attacker never has to touch the model directly.
Is prompt injection a bug that can be patched?
Not in the same way as a parsing flaw. It follows from how models work, so the durable controls are architectural: limit the capability the model can reach, authorise every side effect, keep humans in the loop for high-impact actions and detect anomalous behaviour.
What should a team review first?
Map the instruction layers that reach one model invocation and the capabilities available after the model reads them. Then decide, per action, whether the model's intent is enough or whether the application must authorise it independently.
Primary references and further practice
- TryHackMe: Input Manipulation and Prompt Injection, official room
- OWASP GenAI Project: Top 10 for LLM Applications 2025
- OWASP Top 10 for LLM Applications 2025, full document (LLM01, LLM07)
- For the complement to this note, read the output handling companion or the field note on an agent that disabled its own sandbox, or browse all authorised writeups.