Draw an organisation's AI stack and its trust boundaries.
Load and share models safely.
Lock down notebooks and AI API keys.
Hands-on projects and labs
Deploy JupyterLab in a container with authentication and no secrets, and check it from outside.
Scan a set of public model files with ModelScan and explain any findings.
Search a test repository you own for leaked AI API keys with a secret scanner such as Gitleaks.
Done when you can…
Explain why loading an untrusted pickle file is like running an untrusted program.
Present a map of an AI stack with its top three weak spots.
Beginner
Map the AI stack
List every part: data stores, notebooks, training jobs, experiment trackers, registries, inference servers, vector databases and the APIs in front of them. Each needs an owner and access control.
Jupyter servers left open to the internet give attackers code execution. Require authentication, keep them off public networks and keep secrets out of notebooks.
Pickle-based model files can run code when loaded. Prefer safetensors, scan files before loading, and never load untrusted models on machines with secrets.
Check who published a model, how popular and recent it is, its licence and whether it uses safe formats. Typosquatted model names exist, just like typosquatted packages.
Model API keys are valuable and often leak in code, notebooks and logs. Store them in a secrets manager, scope them, set spending limits and rotate them.
Poisoned datasets, backdoored models, malicious libraries and compromised MLOps tools. ATLAS and the OWASP LLM Top 10 both list supply chain as a top risk.
Deploy MLflow with authentication behind a proxy, then add a review step before a model can reach production.
Sign a model with Sigstore model-transparency and make the serving step refuse unsigned models.
Generate a CycloneDX ML-BOM for a small project with a model, a dataset and its libraries.
Done when you can…
Show a pipeline where only a reviewed, signed model can reach production.
Answer, from records, exactly which data and code produced a deployed model.
Intermediate
Securing MLOps platforms
Experiment trackers, pipelines and registries such as MLflow and Kubeflow have had serious vulnerabilities. Patch them, require authentication and never expose them to the internet.
ML projects pull in huge dependency trees. Pin versions, scan for known vulnerabilities and watch for malicious packages with names close to popular ones.
Harden Kubernetes clusters that run training and inference.
Protect model endpoints from abuse and extraction.
Protect training data and model weights.
Assess third-party model providers.
Hands-on projects and labs
Run a small model server on a local Kubernetes cluster (kind or minikube) with network policies, authentication and rate limits.
Write detections for unusual reads of a model weights bucket in your own cloud account.
Compare two hosted model providers' data retention and security terms and write a recommendation.
Done when you can…
Lead the security design of an AI platform.
Show that a stolen API key cannot download model weights or training data.
Advanced
Kubernetes for AI workloads
Most training and serving runs on Kubernetes. Apply namespaces, network policies, pod security, workload identity and least-privilege service accounts.
GPU drivers and container toolkits have had serious vulnerabilities, and shared GPUs can leak data between tenants. Patch quickly and isolate sensitive workloads.
Training data is often the most sensitive asset. Encrypt it, restrict who can read it, log access and keep production personal data out unless it is truly needed.
When you call a hosted model, your data leaves. Check retention, training use, location and the provider's security, and plan for outages and model changes.
Design an AI platform that makes secure use the default.
Contribute fixes and standards to the open AI ecosystem.
Hands-on projects and labs
Write a reference architecture for a secure AI platform, with registry, signing, serving and monitoring.
Find and responsibly report a vulnerability in an open-source ML tool.
Done when you can…
Own the security of an AI platform used by many teams.
Have your fixes, tools or guidance adopted in the open AI ecosystem.
Expert
AI platform security strategy
Give every team a paved road: approved models, a scanned and signed registry, hardened serving, central secrets and logging, so the secure way is also the easy way.
Find and report vulnerabilities in ML libraries and platforms, help projects adopt signing and safe formats, and share threat intelligence on malicious models.
Behind every AI feature is a stack of infrastructure: notebooks, training clusters, GPUs, data lakes, experiment trackers, model registries and inference servers. Much of it was built for speed by research teams, and attackers have found exposed dashboards, leaked keys and unauthenticated APIs in it.
AI also has a new supply chain. Teams download pre-trained models, datasets and libraries from public hubs, often with little checking. A model file can carry malicious code or a hidden backdoor, and a dataset can be poisoned. This roadmap covers both: the platform and what flows through it.
Why it matters
Organisations are spending heavily on AI platforms and depend on models they did not build. Securing this layer uses familiar cloud, container and supply chain skills, applied to new components, and few security teams cover it yet.
Typical job roles
EntryMLOps or platform engineerBuilds and runs the AI platform with secure defaults.
Mid-levelAI platform security engineerSecures training and serving infrastructure, secrets and access.
Mid-levelAI supply chain security engineerScans, signs and tracks models, datasets and dependencies.
SeniorAI infrastructure security architectDesigns isolation, identity and data protection across the AI platform.
LeadHead of AI platform securityOwns the security of all AI infrastructure and third-party AI components.
Prerequisites
Cloud security basics, ideally the Cloud Security roadmap's beginner and intermediate stages.
Containers and Kubernetes basics.
Software supply chain basics: dependencies, SBOMs and signing.
A working idea of how models are trained and served.