Safety / Eval: How do systems find, block, and fix risk?
Once RAG and agents can read external knowledge, call tools, and affect external systems, failures need to become reproducible tests. This chapter shows how red-team cases, input guardrails, least privilege, human review, regression evaluation, and a release gate form a continuous feedback loop.
Teaching interaction
Safety / Eval Release Gate Lab
Once RAG and agents can read external knowledge and take actions, how can one failure be kept out of future releases?
Normal request
Read-only summarization stays useful
The user asks for a support-ticket summary. The document contains no extra instruction, so the system only needs to read and summarize.
Test request
Summarize ticket #482 and list the confirmed resolution steps.
Expected system outcome
Allow ticket.read, produce the summary, and perform no external write.
1 / 6
Run a normal control case first
The suite records the expected result for a normal request so a guardrail cannot appear safe merely by refusing everything.
What this step provesNormal case
A normal request must retain task success; safety is not blanket blocking.
Learning goals
Distinguish a model that appears capable from a system made more reliable through repeatable evaluation.
Understand why input guardrails, least privilege, and human review must sit outside model output.
See how a failure becomes a regression case that prevents the old bug from shipping again.
Simplification note
This demo calls no real model, tool, or safety service. Requests, detections, permission decisions, and fixes are scripted. It explains defense in depth and regression evaluation; passing one suite never proves that all risk is gone.
Teaching And Evidence Boundary
Passing an evaluation is not absolute safety; it makes known risk measurable, interceptable, and repeatable
NIST places generative-AI risk management across the lifecycle and emphasizes pre-deployment testing, ongoing evaluation, incident records, and periodic review. OWASP explains that prompt injection cannot be eliminated by model instructions alone and recommends least privilege plus human approval for high-risk actions. HELM shows why evaluation needs metrics beyond accuracy, including robustness, safety-related harms, fairness, and efficiency. This demo compresses those principles into one indirect prompt-injection case; it is not a complete security benchmark or compliance program.