AI Platform and Security · Module 4 · Security

Security for AI Systems

The lesson extends security architecture to the parts of an AI system that classical controls do not reach: the model, the prompts and retrieved content that steer it, the data that trained it and the agents that act on its output. Participants map the threat surface with the OWASP Top 10 for LLM applications and MITRE ATLAS, study injection, poisoning and leakage at the level needed to design controls, bring models into supply-chain practice with the ML-BOM, and codify a threat model and guardrail policy.

Lesson 16 of 25Chapter 1690 minutes

Read the chapterThe whitepaperThe slides

All courses / AI Platform and Security / Module 4 / Chapter 16

Learning objectives

After the lesson the participant can:

Key concepts

Single channel for instructions and data
A large language model receives its system prompt, the user's request and any retrieved document as one sequence of tokens, and nothing in the model enforces a boundary between them. The boundary is therefore enforced outside the model.
Indirect prompt injection
Instructions planted in content such as a web page, an email or a shared document that are followed when the content enters the context window. The attacker never touches the application, so every system that reads external content is exposed by construction.
ML-BOM
The CycloneDX Machine Learning Bill of Materials, which records the provenance, licences and training parameters of models and datasets. When a base model is withdrawn, a query over the registry's ML-BOMs lists every model that depends on it.
Threat model as code
A threat model kept in the repository with trust boundaries, threats tagged with OWASP and ATLAS identifiers, and named controls. It is reviewed on every change, because the pull request that adds a source or tool shows the entries affected.
Guardrail policy
The configuration the AI gateway enforces at runtime: allowed retrieval collections, output validation, tool allow-list, actions to confirm and limits. The threat model's control identifiers point to it, so a named control is demonstrably live.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Match

OWASP entries and their primary control

Match each entry of the OWASP Top 10 for LLM applications with the primary architectural control the chapter's table gives.

Interactive exercise 2 · Sort

The review checklist by layer

Sort each item of Nordvik Region's security review checklist under the part of the checklist it belongs to.

Teaching plan

15 minThe teacher walks Figure 16.1 point by point and has participants name, for each point, why a classical control alone does not reach it.
20 minCover the OWASP entries with their primary controls, then the outside-the-model responses to injection, poisoning, extraction and training-data leakage, at the level of design.
15 minRead Nordvik Region's ML-BOM, threat model excerpt and guardrail policy, and trace one control identifier from threat to configuration.
30 minExercise: a security design review of one AI system, producing threat entries and the guardrail settings they point to.
10 minClose with the three reporting clocks one event can start and what the logs must link for the first of them to be met.

Discussion

  1. The checklist puts foundations first because a reviewer who starts with the AI-specific items tends to miss a shared API key. Which foundation is weakest around your AI systems?
  2. None of the controls makes injection impossible; together they make it unprofitable. What is the worst case of a fully hijacked model in one of your systems today?
  3. Could your organisation establish within 24 hours whether retrieved content caused a wrongful action? What would have to be logged for that?

Written exercise

Exercise · 30 minutes

Security design review of an AI system

Review an AI system of your own organisation, or Nordvik Region's casework assistant, as its security architect. Draw its trust boundaries: where user input, retrieved content, tool results and supply-chain artefacts enter. Write four threat entries in the chapter's form, each with an OWASP identifier, the vector described at design level, the impact, the controls and the residual risk; cover at least retrieved content, agent tools and the model supply chain. Then write the guardrail settings those controls point to: allowed collections, output validation, tool allow-list, actions needing confirmation and limits. Finish by listing which checklist items for foundations you could not evidence.

Deliverable: A threat model excerpt with four linked entries, the matching guardrail policy, and a list of unevidenced foundation items.

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

  1. Why is indirect prompt injection described as more dangerous for enterprises than direct injection?

    Show the answer

    D. Because the attacker never touches the application: planted content acts when it enters the context
    Instructions planted in a page, an email or a shared document act when retrieved, so every retrieval system and agent that reads external content is exposed by construction.

  2. What does the chapter say is the property that matters in a codified threat model and guardrail policy?

    Show the answer

    B. Linkage: the threat names the control, the control names the configuration, the pipeline proves deployment
    The chapter states that the property that matters is linkage, not completeness, so that a named control is demonstrably live.

  3. In the casework assistant's prompt section on untrusted content, what does the rule that the prompt contains no credentials record?

    Show the answer

    A. That no control depends on the prompt's confidentiality; the case management API decides authorisation
    The rule addresses system prompt leakage: the prompt enforces no boundary and holds no secrets or authorisation logic.