LLM Security

Introduction Red teaming an LLM application is not the same thing as checking whether the base model passed a benchmark. The deployed application has prompts, retrieval, tools, business rules, memory, hidden context, and user workflows. Those layers create risks that do not exist in the foundation model alone. The course uses two demo applications: a banking assistant and an ebook store support bot. The useful pattern is not the specific brand names or prompts. The useful pattern is the assessment workflow: define scope, probe manually, automate repeatable checks, use scanners where they help, and connect successful attacks to real application impact. ...

Introduction The OWASP Top 10 for LLM Applications is useful because it moves the conversation beyond “the model said something wrong.” In real systems, an LLM is connected to prompts, RAG, vector databases, tools, APIs, logs, users, permissions, providers, and business workflows. That is where the risk lives. A bad response is a quality problem. A bad response that triggers a tool call, leaks internal context, writes to a ticketing system, executes generated SQL, or retrieves another user’s documents becomes a security problem. ...

Introduction I recently completed the Web LLM attacks learning path from PortSwigger Web Security Academy. I already had a foundation in LLM security from the DeepLearning.AI courses I took earlier this year: red teaming, guardrails, quality and safety evaluation, and LLMOps. My notes from those courses are in this same section. They mostly look at LLM applications from the builder’s side, meaning how to evaluate them, monitor them and put controls around them. ...