How to use this book
Who this book is for
This book is for people who protect LLM applications and agents. It is written for security reviewers of AI products, security engineers and agent platform developers. It assumes you have built at least one feature with an LLM API (about the level of the Red Belt LLM API Developer course) and know the basics of web application security (authentication, authorization, XSS, SQL injection and secrets management). With that background, you can use this book alone to study the full AI Security Specialty syllabus.
This book takes a defender's perspective. Rather than "which attacks exist," it focuses on building the judgment to decide "which control belongs where to limit damage." Attack techniques are explained only as far as you need to recognize them, prevent them and test your own system. The book contains no working attack strings or procedures targeting other organizations' systems. Red-teaming exercises always direct you to use your own authorized systems and fake data.
It does not go deep into general network security (firewalls, intrusion detection and network isolation) or research on attacks against model training (generating adversarial examples and extracting training data). It does, however, cover practical decisions operators must make about supply chains and data poisoning.
How this book is organized
Each of the five chapters covers one exam domain. Chapter 1, Threat modeling, draws the map. Chapter 2, Prompt injection, examines the largest threat. Chapter 3, Data protection and permissions, teaches designs that limit damage. Chapter 4, Defense testing and red teaming, measures whether those designs work. Chapter 5, Operational security and incident response, covers what happens in operation. The hands-on tasks are linked so that the output of one chapter becomes the input to the next.
Every chapter has the same ten sections. Learning objectives and Introduction set the direction; Key concepts and Going deeper cover the substance and trade-offs; and two workplace scenarios walk through the decisions. These are followed by Common mistakes, Summary at a glance, Check the official docs, Self-check (answers in Appendix B) and Hands-on tasks lasting 30–60 minutes.
Appendix A is a glossary, Appendix B gives self-check answers and explanations, Appendix C is an exam day guide, and Appendix D lists the official documents cited in this book. Read the chapters in order the first time. On later readings, focus your review on the Common mistakes and Summary at a glance sections.
The exam at a glance
The AI Security Specialty exam has 35 questions to answer in 60 minutes. Each question carries a weight: questions that check a concept or apply one principle are worth 2 points; analytical questions that require considering several conditions together are worth 3 points. Your earned points are converted to a raw score out of 100; a score of 75 or more is a pass. A grade from 1 to 9 is also shown based on your raw score. The free practice set consists of 10 questions with a 25-minute limit.
| Chapter | Domain | Weight |
|---|---|---|
| Chapter 1 | Threat modeling | 20% |
| Chapter 2 | Prompt injection | 25% |
| Chapter 3 | Data protection and permissions | 20% |
| Chapter 4 | Defense testing and red teaming | 20% |
| Chapter 5 | Operational security and incident response | 15% |
Prompt injection has the largest weight, but actual questions combine domains. An injection question may be answered by reducing permissions (Chapter 3); a red-teaming question may be answered by the threat model (Chapter 1). Rather than memorizing chapters separately, understand one continuous process: find paths, limit damage, measure effectiveness and operate the system.
What the questions look like
The exam paper resembles the question booklet and OMR answer sheet used for Korea's CSAT (Suneung). In every format, you answer by selecting one numbered option (①–⑤). Questions are constructed in five formats, which appear on the paper as follows.
| Format | What it looks like on the paper | What makes an answer correct |
|---|---|---|
| Single-select multiple choice | One of five options | The one most appropriate option |
| Combination selection | Combinations containing a specified number of items labeled A, B, C… in a <Statements> box |
A combination containing every correct item and no incorrect ones |
| Statement evaluation | Combinations of only the correct statements in a <Statements> box |
Both the conclusion and the reason must be correct for a statement to be correct |
| Ordering | Five possible sequences for steps (a)–(e) | An order in which the output of an earlier step becomes the input to a later one |
| Matching | Five possible pairings of left-hand items with right-hand choices | An option with every pair correct; one choice may be left over |
Most questions present a short workplace scenario and ask for a decision. Each scenario contains one or two conditions in bold. For example, if the launch schedule cannot change, an option requiring months of redesign cannot be correct, however safe it is. If the question asks for a control enforceable in code, eliminate an option that adds a sentence to the system prompt. Analytical questions are designed so that changing one condition changes the answer: selecting by keyword alone leads to a plausible wrong answer. For each option, ask whether the measure satisfies every condition in the scenario or only some of them.
Key point
In statement evaluation questions, an incorrect reason is the most common trap. A statement with the right conclusion but an unrelated justification is incorrect.
Six-week study plan
This plan assumes one hour a day, five days a week. If you have extensive practical experience, you can combine weeks 1 and 2 into one week.
| Week | Scope | Weekly output |
|---|---|---|
| Week 1 | Chapter 1, Threat modeling | A data flow diagram and trust boundaries for an LLM feature you know, plus a draft risk register |
| Week 2 | Chapter 2, Prompt injection | A list of injection paths and a mitigation matrix for each path |
| Week 3 | Chapter 3, Data protection and permissions | A plan to reduce tool permissions and an output-rendering checklist |
| Week 4 | Chapter 4, Defense testing and red teaming | An evaluation set of 30 cases, scenario cards and a metric calculation sheet |
| Week 5 | Chapter 5, Operational security and incident response | An incident response runbook and audit log field definitions |
| Week 6 | Appendix review, practice set and review of mistakes | Review notes for the practice set and a revised list of common mistakes |
Key point
Actually do the hands-on tasks. On this exam, the gap between "what you know from reading" and "what you have designed yourself" shows up in your score. In particular, the week 2 and week 4 tasks use the same reasoning as the exam's analytical questions.
Notation and sources
The standards, vendor and legal information in this book was checked against the respective official pages on October 20, 2026. The reference editions are the same OWASP Top 10 for LLM Applications 2025 edition used by the exam (a reordered 2026 edition appeared in August 2026; Chapter 1 provides a crosswalk), OWASP Top 10 for Agentic Applications 2026 (published in December 2025), Model Context Protocol (MCP) version 2026-07-28, and Korea's Personal Information Protection Act (PIPA) and its Enforcement Decree as in effect on September 11, 2026. Product names, settings screens and feature scope can change, so check each chapter's official documents before applying anything in practice.
The notation principles are as follows.
- Product, API and parameter names retain their original spelling (
tool_result,safety_identifier, Prompt Shields). - Terms are explained on first use and used consistently thereafter. For example, the same term, "excessive agency," is used throughout.
- Features, limits and prices not confirmed by vendor documentation are omitted. Unverified points are explained only as general principles without naming a particular vendor.
- Laws are cited from the current provisions in Korea's National Law Information Center. The legal explanations in this book are not legal advice. In an actual incident, follow the judgment of your privacy officer and legal team.
- All organizations and people in the examples are invented.
Note
This book contains no working attack strings. Attack examples describe only their structure, such as "instructions addressed to the model, placed inconspicuously at the bottom of a document." Follow this principle when building evaluation sets too.