Launching with OC-AISF and OC-AIRT · Team programmes scoped on enquiryODA3 Institute ↗
Sign inEnquire
OC-AISFASD · AI Security: DefensiveFoundationIn development

AI Security Foundation

Priority 1 · in the launch sequence

LevelFoundation
PrerequisitesNone
StatusIn development
SpecificationDraft · not approved
EnrolmentNot yet open

01Overview

The entry point to the curriculum: the AI threat landscape, an attack taxonomy and core defensive principles, drawn from documented public cases.

Domain scope · ASD

The defensive core: AI threat taxonomy, control-plane implementation, token security, pipeline and model integrity, and AI incident response.

Intended for: Security practitioners moving into AI security or deepening it

02Learning outcomes

Proposed
  • Trace a request through an AI system and name its trust boundaries
  • Distinguish application-layer attacks from model-layer compromise
  • Apply foundational token and credential controls to AI systems
  • Read and apply SHALL, SHOULD and MAY control requirements
  • Triage an AI incident report using a four-phase method
  • State what evidence shows a control is working, and what it cannot show

03Proposed case references

Source review pending
I-3
OpenClaw/ClawHub MCP Marketplace CrisisSource review · In review
I-4
Meta Internal AI Agent Sev 1Source review · In review
I-5
Context AI/Vercel OAuth Supply Chain BreachSource review · In review
I-6
Adaptive AI Infrastructure CampaignSource review · In review

Proposed connection, subject to source review. The threat taxonomy taught here follows the attack classification applied to cases I-3 to I-6. Learners use the same categories used to classify these documented cases, not a taxonomy built from scratch.

04Proposed framework references

Under review
NIST AI RMF · GOVERN 1.1ISO/IEC 42001 · Clause 6.1.2EU AI Act · Art. 9(2) (introduced)IETF RFC 2119

Control framework alignment and control level are published with the approved specification. Referencing a framework does not mean its publisher has approved or endorsed a course.

05How a request crosses an AI system

Proposed
Figure 1 · Request path and trust boundariesIllustrative
TRUST BOUNDARY 1TRUST BOUNDARY 2 Untrusted inputPrompts, files, web textGuard layerInput and policy checksInference coreModel and contextAction brokerTool calls and permissionsTools & dataAPIs, stores, systems Retrieval store ABC REQUEST PATH →
A = where untrusted content enters, B = where model context is assembled, C = where actions leave the system. Lab 01 asks learners to draw this map for a real configuration.

06Syllabus

4 modules · 9 topics · proposed
01

AI threat landscape and system boundaries

  • Components and trust boundaries
  • Where AI differs from conventional software
02

Threats to data, models and applications

  • Threats across the lifecycle
  • Reading a public incident disclosure
  • Lab 01 · Trace a request through an AI pipeline
03

Defensive principles and control context

  • Token and credential lifecycle
  • SHALL, SHOULD and MAY in practice
04

Applying concepts to incident material

  • A four-phase triage method
  • Lab 02 · Triage an AI incident report

07Practical labs

Proposed
Lab 01 · Trace a request through an AI pipelineGuided lab
Scenario
A deployed AI assistant with retrieval, tools and an API.
Inputs
Architecture diagram, configuration extract, request log.
Task
Follow one request and mark where identity, data or configuration could change.
Output
An annotated pipeline map naming each trust boundary.
Criteria
Completeness, accuracy, support from the inputs.
Lab 02 · Triage an AI incident reportGuided lab
Scenario
A published incident disclosure involving an AI system.
Inputs
Disclosure text and a timeline extract.
Task
Classify it, separate known from unknown, choose next steps.
Output
A short written triage note.
Criteria
Classification, stated limits, justified next steps.

08Assessment

Proposed · draft specification
Written exam90 min

Covers all four modules

Pass mark70%

Retake rules in the regulations

Practical2 labs

Both reviewed against criteria

Proposed rule: a passing exam score alone would not be enough; both labs would also need to be passed.

09Instructor

TBA
Announced when appointed

Instructors are practitioners appointed against a written standard for the ASD domain.

How faculty are appointed →

Official specification registerOC-AISFSpecification not yet issued
Version Last reviewed
This course is in active development. Duration, pricing, session dates and instructor are published when confirmed. Proposed case references, framework references, syllabus, labs and assessment are drafts until the course specification is approved.