Security Overview
Security and privacy for AI applications: threat models, data protection, compliance frameworks, and defense-in-depth.
Last updated
Security Overview
The pillar that quietly fails FDE candidates: they recite acronyms instead of threat-modeling the system in front of them. The hub for the Security & Safety part.
Ask ten candidates to “talk about security” for an LLM support agent and nine answer “IAM, encryption, SOC 2” and stop. That fails twice: it names controls with no threat they defend against, and it ignores what makes an LLM app different — the model reads untrusted text as instructions, retrieved data becomes prompt content, outputs are actions with side effects. The passing answer has a thirty-second shape: threat model first, then layered defenses, then ownership.
“I’d start from a threat model, not a control list: walk the data flows with STRIDE and mark every trust boundary — user input, retrieved documents, tool calls, the provider API. Then defenses in layers: identity and least privilege, PII redaction before the model, injection screening on everything the model reads, tenant isolation, encryption with our own keys, immutable audit logs, zero retention at the provider. Finally, ownership: which risks we accept, who signs them, and how each control maps to SOC 2 / GDPR evidence.”
Threat model → layers → ownership — the skeleton for this whole part.
You built the failure taxonomy in SD-9 · Agent Failure Modes — loops, tool errors, context rot, cascading hallucinations. Security failures are the same mechanics with one difference: an adversary causes them on purpose. This is the hub; the deep-dives carry the code and configs.