Overview
By this point in the course, our applications can do much more than produce text. They can call tools, retrieve local information, and return structured outputs. That increased capability also creates new risks.
Some risks are familiar from ordinary software engineering: permissions, access control, logging, and privacy still matter. Other risks become more visible because the application now mixes probabilistic behavior with prompts, external data, and automation.
Figure 1 shows a simplified view of the attack surface.
Security as engineering
0 / 5 points
A team says security and responsible use can be added after the LLM application is already finished. Which statement best explains why that is a mistake?
This part focuses on practical engineering judgment:
- how LLM systems can be attacked,
- how they can be defended,
- when human oversight is necessary,
- and how privacy, copyright, bias, and disclosure affect design choices.
The structure of the part is as follows:
- Attacking LLM Systems introduces prompt injection, data leakage, tool misuse, and other common risks.
- Defending LLM Systems focuses on concrete safeguards and trust boundaries.
- Human Oversight and Appropriate Automation discusses how much control should remain with people.
- Privacy, Copyright, Bias, and Responsible Use connects technical choices to broader responsibilities.
- Case Study: Assessing an LLM System brings the course together in one structured analysis.
Finally, Recap and Feedback closes the course.