Academy learning group 1 · Academy module (not an ISO clause) M01 · Chapter 1 of 8
Map AI assets and lifecycle trust boundaries
About 5 minutes · ISO/IEC 27090:2026 · Published AI-security guidance
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
See it · Try it · Recall it
Picture the topic
Remember this: Protect the data, the model and the service around it.
Explore the anchors
Track training evaluation and operating inputs.
Concept matching activity
Match this task or description to its concept:
Protect artifacts parameters and approved versions.
Choose a concept before checking the explanation.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
What this chapter explains
- Concepts and distinctions
- Apply the process and collect evidence
Concepts and distinctions
An AI system includes more than its model file. Data sources, labeling workflows, training jobs, evaluation sets, artifact stores, serving interfaces and connected tools can all create security boundaries. A failure in one dependency can undermine the behavior of a system whose model metrics previously looked good.
ISO/IEC 27090:2026 is guidance on AI-specific security threats and compromises across the lifecycle. It complements ordinary cybersecurity practices rather than replacing identity controls, configuration management, logging or incident handling. This course uses public scope information and original practical explanations; its module numbers are academy references, not a verified reproduction of the standard’s detailed clauses.
Apply the process and collect evidence
Create a simple system map naming owners, data flows, trust changes and permitted actions. Distinguish people who can supply data, approve a model, deploy a version or authorize a tool action. State the attacker’s assumed access before evaluating a threat. Connect technical effects to business and safety consequences, and retain evidence of the chosen safeguards and their limits.
| Concept | What to remember |
|---|---|
| Data | Track training evaluation and operating inputs |
| Model | Protect artifacts parameters and approved versions |
| Service | Restrict interfaces tools and deployment authority |
Worked example
A document assistant uses approved model weights but can read an unmanaged document store and call a broadly privileged service account. The model’s approval does not establish the integrity of retrieved content or the safety of tool permissions. Map the document, model and service boundaries separately. Restrict the connected identity and validate requested actions outside the model’s generated text.
Check your understanding
An approved model uses a broadly privileged tool identity. What remains a security concern?
Show explanation
The surrounding data and action boundaries can still permit unauthorized behavior. Model approval does not replace system-level authorization and data controls.
Source and study boundary
Official standard overview. The reference identifies the topic being taught. Explanations and examples are original academy material; a topic link does not establish independent approval or sufficient exam mastery.