Most security intuition assumes a trustworthy program processing untrusted input: validate the input, and the code does the right thing. A language model breaks that assumption. The thing reading the input is itself non-deterministic and steerable, so you cannot fully trust the model's behaviour - and because its output flows on into browsers, databases, and tools, you cannot fully trust that output either. Three untrusted surfaces replace one. And there is no fixed grammar to sanitise: natural language has no parser that cleanly separates 'instruction' from 'data', so input validation can never be as complete as it is for SQL or HTML. Defences stop being binary - blocked or allowed - and become probabilistic: a guardrail lowers the odds of a bad outcome, it does not prove one impossible.

You do not need the math to reason about this - you need five words. The model reads text as tokens, subword fragments where 'instructions' and 'data' look identical. It holds a bounded number of them in its context window, a working memory; anything outside it does not exist to the model. Its weights were shaped once during training and are frozen at inference - it learns nothing from your chat, it only predicts the next token from what is in context. It represents meaning as embeddings, vectors where nearness means similar meaning - the idea retrieval and RAG run on. And it chooses each next token with a randomness dial called temperature, which is why the same prompt can give different answers and why testing a control once proves little.

Zoom out and the whole application appears as a pipeline: a user prompt enters, your app's orchestration assembles the full prompt, the model reads it, output comes back, and that output flows into a sink - a browser, a database, an API, a shell. Two side-channels feed the model extra context along the way: a retrieval / vector store (RAG) that pulls in documents, and a tools / agents / plugins layer, including MCP, that lets the model act in the world. This map is the single most useful thing in Foundations, because every OWASP LLM Top-10 risk is just a label on one edge or box of it. You are only meeting them here for the first time; you will attack and defend each one on its own path - RAG in LLM09, tools and agents in LLM03 (Excessive Agency), and so on.

Look closely at the 'prompt' box and it is not one blob but a structured conversation: a system message with the app's standing rules, the user's messages, the assistant's own turns, sometimes seeded with few-shot examples and delimiters that mark sections. Prompt engineering uses that structure to get better answers. Prompt injection abuses the fact that, once assembled, it is all one token stream - so attacker text like 'ignore previous instructions' can pose as a higher-priority role. Same structure, opposite intent. The platform, not the model, is what keeps roles apart, and a delimiter written in text is one an attacker can forge or close.

If you come from application security, the fastest way in is by analogy - as long as you keep the caveats. Prompt injection rhymes with SQL injection: untrusted input crossing into a command context. Improper output handling rhymes with XSS: untrusted output crossing into a renderer, and here the classic fix, context-aware output encoding, largely transfers because the sink has a real grammar. The trust-boundary lens transfers cleanly. What does not transfer is the completeness of the fix: classic injection has a formal grammar and a provably-correct solution, like parameterised queries; LLM injection has neither, so you cannot 'escape' a prompt the way you escape a query. The analogy tells you where to look; it overstates how completely you can close the hole. If CIA, crypto basics, and common web vulnerabilities are already familiar, you can skip that refresher entirely - none of it is required to continue.

That is the whole mental model. From here the curriculum follows the OWASP LLM Top-10 - a community-built list of the ten most important LLM risk categories - along one of two tracks: an Offensive (Pentester) track where you attack a live target to feel how each risk breaks, and a Defensive (Developer and Defender) track that is defence-first and needs no attack prerequisite. Every path runs the same Attack, Defend, Verify loop against a real target, it is self-paced, and it keeps no points or leaderboards - the only signal is whether the target actually did what you set out to make it do. Two rules govern all of it: test only systems you own or are explicitly authorised in writing to test, and keep everything you learn inside that scope. That is the only ethics stop on the tour - not a lecture, a scope line.

© 2026 GenAI Security Lab. All rights reserved. You may read, quote, and link to this material with attribution. Copying, republishing, redistribution, resale, or use to train models or build competing products is prohibited without prior written permission.