Harden
Fix the findings in priority order with defense in depth, then prove each fix with a re-attack — the remediation half of the assessment.
Findings without fixes are a complaint. This week you harden — remediate the vulnerabilities you found, in risk order, with the layered defenses of this course, and prove each fix by re-running the attack that found it. Budget four to six hours; the discipline is fix-then-verify, never fix-and-hope.
The remediation order
- 1Critical first — anything that lets an attacker take a harmful action or exfiltrate data. These usually resolve to privilege fixes (least privilege, action validators, scoped credentials) because those bound blast radius regardless of the model.
- 2Then High — leakage paths, effective injections, missing output validation.
- 3Defense in depth per finding: don't fix an injection with only a prompt tweak; add the layer that makes it harmless (privilege/validator) plus the layer that makes it harder (screening/hardening). Every fix should degrade gracefully if one layer fails.
- 4Some findings you accept and document — a low-severity issue with a costly fix may be a written, risk-accepted decision rather than a change. Documenting accepted risk is itself a professional practice.
Prove every fix
- 1For each remediated finding, re-run the exact attack that exposed it. It must now be blocked, flagged, or harmless — with evidence (the trace showing the validator firing, the redacted output, the scoped denial).
- 2Add each attack to your red-team suite so the fix is a permanent regression test — the flywheel from LLMOps, now guarding security. A fix that isn't in the suite will be un-fixed by a future change, silently.
- 3Run the full suite and your quality eval together: confirm the hardening closed the holes and didn't break the product (over-aggressive guardrails that block legitimate users are a failure, not a win).
The before/after posture
Track your security posture as a number: attack success rate before hardening vs. after, by category, with the critical-action success rate at zero as the non-negotiable bar. That before/after — say, '18 of 45 attacks landed, 6 causing harmful actions → 0 harmful actions, 3 flagged-but-harmless, suite in CI' — is the headline of your report and the proof your week's work mattered. Be honest about what that zero means, though: zero harmful actions over a finite attack suite is a floor you must clear, not proof that no attack exists — a payload you didn't think to write could still land. State the coverage limits in the report (how many cases, which channels, which categories) and carry the gap into your residual-risk section (the m6-report lesson) rather than presenting zero as absence of risk.
Here is a finding, my proposed fix, and my re-attack result: [paste one]. Pressure-test the fix: is it defense-in-depth or a single point of failure? Could a variant of the attack bypass it? Did it introduce a new problem (a false-positive that blocks real users, a new attack surface)? What's the one thing you'd add to make this fix robust?
The hostile review of your own remediation. Single-layer fixes and fixes-that-broke-something are the two most common hardening mistakes; this catches both.
End of week, freeze the hardened system and run the full red-team suite one final time, clean. The report's numbers come from this frozen run, not from your memory of fixing things. A posture claim backed by a reproducible suite run is trustworthy; one backed by 'I fixed all that' is not.