Skip to content
Free public beta until December 4, 2026: every course is open, no card needed. After that, the first chapter of each course stays free and full access is a one-time $39 ($19 for up to 100 founding members chosen for helpful feedback). Your progress is kept. How the beta works

Recipe

Harden an LLM application end to end

Use when: you're shipping an application that lets a model read content the team doesn't fully control -- user input, retrieved documents, tool results. You want a concrete, ordered checklist of defenses, not just the general idea

Goal: a stack of independent defenses applied at the right point in the pipeline. No single missed defense should ever be the only thing standing between an attacker and a real result

Taught in Audit logging and defense in depth

Quick recipe

  1. Check untrusted input before it reaches the model
  2. Grant only the access this task actually needs
  3. Sandbox any action whose behavior isn't fully predictable
  4. Check the model's output before it reaches a user or another system
  5. Require a person's sign-off for risky, hard-to-undo actions
  6. Log every step, with secrets redacted
  1. 1

    Check length, format, and encoding on anything the team doesn't fully control. Treat a pass as narrowing the attack surface, not as proof the input is safe.

    Why: this is the first point in the pipeline where untrusted text can be checked. It happens before the text is even built into a prompt.

  2. 2

    Scope every login, database connection, and tool to the narrowest access the current task requires. Never grant more "just in case."

    Why: if every other layer fails, least privilege is what limits how much damage the failure can actually cause.

  3. 3

    Run model-written code, or any action reaching outside the application's own data, inside a walled-off space. Give it no unneeded network or file access. When the action itself can't really be walled off -- a real refund, a real email -- lean on the next step, required confirmation, instead of isolation.

    Why: this limits where a single action's effects can reach, whether or not that action was itself a mistake.

  4. 4

    Check for leaked secrets, banned content, and an action that traces back to an untrusted instruction rather than a real request.

    Why: this is the last point before a reply or action leaves the system's own boundary. It is the second half of Section 1's two-boundary check.

  5. 5

    Whatever scope and containment remain, a truly high-stakes action still gets a human glance before it actually runs.

    Why: Chapter 12/14's confirmation step catches exactly the narrow, high-risk piece. Every earlier layer was built to shrink that piece, not remove it.

  6. 6

    Record every tool call, retrieved document, and reply, with enough detail to rebuild the sequence later. Never log a plaintext key.

    Why: every layer above can still fail; a log is what lets a team find out that it did, and how, after the fact.

Common mistakes

  • Treating one layer, usually input validation alone, as enough, and skipping the rest.
  • Logging a key's actual value instead of just the fact that it was used.
  • Sandboxing a risky action but granting the sandbox itself broad access "since it's isolated anyway."
  • Checking input but never checking output, so a successful injection's effects can still flow straight through.