Most LLM safety work assumes the threat is an adversarial user attacking the system. I ship for the inverse: production AI applications where the threat is the system itself attacking a vulnerable user. The defensive controls turn out to be the same primitives security engineers already use, applied to a non-traditional threat surface.
I build software for three audiences who share one thing: a generic AI response will hurt them. Couples planning their wedding, in the most emotionally loaded purchase of their lives. Families of missing people, in active grief and vulnerable to anything that sounds like false hope. And anyone capturing their own worst moments in a private journal, where a chipper AI cheerleader does real damage. The interesting design work in each of these production systems is not what the AI is allowed to say. It is the words that are forbidden, the pauses that are forced, and the protected modes the system locks itself into when it notices the user isn't okay.
This talk walks through the actual code from three live products. A Claude-powered email agent for wedding venues with a routing layer that pulls high-stakes conversations away from the model entirely. A missing-persons intelligence platform with epistemic disclaimers banning words like "confirmed" and "matched" at the prompt level, plus a post-generation validator that catches them when the deny-list fails. And a personal AI companion that detects emotional-state signals from user input and auto-locks the session into a protected mode where features quietly switch off.
Attendees leave with a portable pattern language for defensive controls in user-harm threat models: when to forbid at the prompt layer, when to route around the model, when to validate after generation, and when to lock the session down entirely. With production code, real metrics, and the failure modes that taught me to add each control in the first place.