Every defence on this slide that inspects text — delimiters, instruction hierarchy, injection classifiers — raises the cost of an attack. None of them ends it. The reason is structural, and worth saying precisely: in every other injection problem in computing there is an escape character. SQL has quoting. HTML has entity encoding. Shell has argument arrays. Each works because the parser has a hard, mechanical boundary between code and data.

A transformer has no such boundary. Your system prompt, the user's message and a retrieved document arrive as one flat sequence of tokens, and "these tokens are instructions, those are data" is a preference learned in training, not a rule enforced by the machine. A preference can be outvoted by a sufficiently persuasive sequence — which is exactly what a jailbreak is. This is why the honest slide two ahead says there is no secure AI agent, and why OWASP has kept injection at #1 rather than marking it solved.

So stop trying to make the model trustworthy, and make the damage impossible instead. The one framing that reliably predicts whether an AI feature can be catastrophically exploited: danger needs all three of these at once.

Remove any one leg and the exfiltration attack dies, regardless of how clever the prompt was. That is a design decision you can actually verify, unlike "our filter catches it." A RAG bot that reads private notes and is fed untrusted documents is fine as long as it cannot transmit. Add one innocent-looking "email this summary" tool and you have completed the triangle.

Practical consequences, in order of value: give the model the narrowest possible tool set; make anything that writes, spends, or sends require a human click; never let a tool's output expand the model's permissions; run the model with the privileges of the user who asked, never with the app's own; and treat every tool result as hostile input — because in an indirect injection, it is. Match trust to blast radius, and the blast radius is something you control even when the model is fooled.

Look at the rate under the calculator: $1.50 in / $9.00 out per million tokens. Output costs six times input, and every provider prices this way. That asymmetry is not arbitrary — it falls straight out of the KV cache from Session 1. Input is prefill: the whole prompt goes through in parallel, once. Output is decode: one sequential pass per token, and nothing about it can be batched away.

Which flips the intuition most people start with. Stuffing 20 extra chunks into a RAG prompt is annoying but survivable. Letting the model ramble for 800 tokens when 150 would do costs far more — and you pay it on every single request, forever. Capping output length is usually the highest-leverage line of code in the whole system, and it's one parameter.

The number that actually matters is cost per user, not cost per call. Do this arithmetic before you build, because it decides the architecture: cost/user/month = queries per user × (input tokens × in-rate + output tokens × out-rate). Ten queries a day at ₹0.30 (about $0.003) each is ₹90 ≈ $0.95 per user per month — fatal for a free app, irrelevant for one billed at ₹2,000 ($21). Same code, opposite verdict. Run it at 100 users and at 100,000; if those two answers don't both work, you have an architecture problem, not a pricing problem.

Two habits that separate a demo from a product: log tokens and cost per request from day one — you cannot optimise a number you never recorded — and set a hard spend alert on the key before you launch, because the first thing a runaway agent loop does is spend money quietly.

"Latency" is two numbers, and averaging them hides the fix. Time to first token is your prefill — dominated by prompt length, and the only part the user experiences as waiting. Tokens per second is your decode — it sets how fast the answer unspools once it starts. A long RAG prompt hurts the first; a long answer hurts the second. Streaming is powerful precisely because it exposes only the first number: 800ms to first token then a steady flow feels alive, while 4 seconds of nothing followed by an instant wall of text feels broken — even though the second one finished sooner.

And never report the mean. Report p50 and p99: the median is the experience you designed for, the 99th percentile is the experience that generates complaints. With LLMs the gap is unusually wide, because response length varies and long tails are structural. If p50 is 2s and p99 is 30s, one user in a hundred is watching a spinner for half a minute — and an average of 2.4s tells you none of that.

Then log what makes debugging possible: a request id, the prompt version, the model id, input and output token counts, latency split into TTFT and total, cost, and the user's thumbs up/down. Prompt version and model id matter more than they look — when quality drops next Tuesday, the first question is always "what changed?", and a provider silently updating a model behind an alias is a real answer you can only reach if you recorded it.

The habit that ties the whole course together: your Session 2 eval set, run automatically before every prompt change, with the score written into the log. Quality then behaves like any other engineering metric — it has a number, a history, and an alarm — instead of being something you find out about from users.