Fundamentals of AI

Where this page sits

Level: Beginner. No maths beyond arithmetic. No prior AI exposure assumed.

This is rung one of Track C — AI literacy for security people. The ladder for the whole site runs:

If you cannot yet open a terminal, cd into a directory, and run docker compose up, go do the Linux substrate track first. Everything from here assumes that much and no more.

If you already know what a confusion matrix is and can explain why a softmax output is not a probability of being right, you are past this rung. Skip to AI Literacy: Thresholds and Confidence, or straight to the attack and defence track.

Four words, nested

The single most common confusion in security conversations about AI is treating four different words as synonyms. They are not synonyms. They nest, like this:

┌─ Artificial Intelligence ───────────────────────────────────┐
│  Any system that performs tasks associated with human       │
│  intelligence. Includes hand-written rules and search.      │
│                                                             │
│  ┌─ Machine Learning ────────────────────────────────────┐  │
│  │  Systems whose behaviour is fitted from data rather    │  │
│  │  than written by a programmer.                         │  │
│  │                                                        │  │
│  │  ┌─ Deep Learning ─────────────────────────────────┐   │  │
│  │  │  ML using many-layered neural networks.         │   │  │
│  │  │                                                 │   │  │
│  │  │  ┌─ Generative AI ──────────────────────────┐   │   │  │
│  │  │  │  Deep models that produce new content:   │   │   │  │
│  │  │  │  text (LLMs), images, audio, code.       │   │   │  │
│  │  │  └──────────────────────────────────────────┘   │   │  │
│  │  └─────────────────────────────────────────────────┘   │  │
│  └────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

Artificial intelligence is the widest term and the least useful one. It is a marketing category as much as a technical one. A chess engine that searches game trees is AI. A rules engine that fires an alert when a login comes from two countries in an hour is, by most definitions, AI. Neither one learns anything. When a vendor says "AI-powered", they have told you nothing; the question you need answered is which of the inner boxes they are in.

Machine learning is the meaningful boundary. An ML system's behaviour comes from fitting parameters to data rather than from a programmer writing the decision rules. That is the whole distinction, and it has a direct security consequence: if the behaviour comes from the data, then whoever controls the data controls the behaviour. Every data-poisoning concern in the rest of this curriculum descends from that one sentence.

Deep learning is machine learning using neural networks with many layers. The word "deep" refers to layer count, nothing more. Deep learning earns its place because it learns its own features. A classical ML pipeline needs a human to decide that "number of capital letters in the subject line" is a feature worth measuring; a deep model learns whatever representation the training signal rewards. That is powerful and it is opaque, and the opacity is why explaining a deep model's decision is a research problem rather than a documentation task.

Generative AI is a subset of deep learning that produces new content rather than a label. A classifier answers "which bucket?"; a generative model answers "what comes next?". Large language models are generative models over text tokens. The distinction matters enormously in security, because a classifier's failure mode is a wrong bucket, while a generative model's failure mode is fluent, plausible, structurally correct output that is false. Those two failure modes need completely different controls.

Supervised versus unsupervised: read the data, not the algorithm

Learning paradigms are usually taught as a list of algorithm names. That is backwards. The paradigm is determined by what your data looks like, and the algorithm follows.

Supervised learning means your training data has labels. Every example comes with the answer attached: this email is phishing, that one is not; this binary is ransomware, that one is a legitimate installer. The model's job is to learn the mapping from example to label well enough to label examples it has never seen. Supervised learning is the workhorse of security ML, and its bottleneck is never the algorithm — it is the labels. Labelling ten thousand emails correctly is expensive, tedious, and requires the people who are least available.

Unsupervised learning means your data has no labels. You have a pile of events and no ground truth. The model's job is to find structure: which events group together, which ones sit far from everything else. Clustering and anomaly detection live here. Unsupervised methods are attractive in security precisely because labels are scarce — but they come with a hard limitation that is routinely glossed over in product marketing: an unsupervised model finds unusual, and unusual is not the same as malicious. A scheduled quarterly report job that only runs four times a year is deeply unusual. It is also fine.

Two more paradigms come up often enough to name:

Self-supervised learning is how modern language models are pretrained. The labels are manufactured from the data itself — hide the next token, ask the model to predict it, compare against what was actually there. It behaves like supervised learning mathematically but needs no human labelling, which is exactly why it scaled to internet-sized corpora when hand-labelled approaches could not.

Reinforcement learning trains an agent by rewarding outcomes rather than by correcting individual predictions. In the LLM world you meet it as the alignment stage that turns a raw next-token predictor into something that follows instructions and declines certain requests. It matters to you mostly as context: the "refusals" you will later try to bypass are a learned preference, not a filter bolted on top.

A model is a file

This is the single most clarifying idea for a security person, and it is almost never stated plainly. A trained model is a file on disk. It has a path, a size in bytes, an owner, a permission bitmask, a format, and a supply chain. Everything you already know about handling untrusted files applies to it.

What is inside that file is two things: an architecture (the shape of the computation — how many layers, how wide, how they connect) and the parameters, usually called weights (the numbers that were fitted during training). Load the architecture, pour the weights into it, and you have a function you can call. That is all "loading a model" means.

Pull a small model locally and look at it. This is the whole point of the exercise — make the abstraction concrete.

# CPU-ONLY. No GPU required. ~1.3 GB download.
docker compose up -d
docker compose exec ollama ollama pull llama3.2:1b
docker compose exec ollama ollama list

NAME               ID              SIZE      MODIFIED
llama3.2:1b        <id>            1.3 GB    2 minutes ago

# Where does it actually live? Find the blobs.
docker compose exec ollama sh -c 'ls -lh /root/.ollama/models/blobs | head'

The largest blob in that directory is the weights. It is a file. You could copy it to a USB stick. You could also replace it with a different file, and unless something checks the digest, the next inference call would happily run whatever you put there. Hold onto that thought — it is the seed of the model-supply-chain material later in the curriculum.

Model artefacts come in several formats, and the format is a security property:

That table is worth memorising. "Download this pre-trained model" and "download and execute this binary" are the same sentence when the artefact is a pickle. The existence of safetensors as a format is itself the industry admitting the problem.

Training and inference are two different programs

People say "running the model" for both, which hides the most important operational distinction in the field.

Training consumes data and produces a model. It is done rarely, on expensive hardware, by a small number of people, usually offline. Its inputs are the training corpus, the labels, and a pile of hyperparameters. Its output is that file on disk.

Inference consumes a model and an input and produces an output. It is done constantly, cheaply, often on commodity hardware, and it is the part exposed to the world. Its inputs are the model file and whatever the user sends.

Two things follow from that table, and both are worth carrying into every AI security conversation you have.

First, training-time compromises are the quiet ones. A poisoned classifier is not visibly broken. It works normally on everything except the pattern the attacker planted, and it keeps working normally for as long as that model is deployed. There is no alert for it. Detection means evaluation discipline, not monitoring.

Second, inference-time is where the users are, so it is where most of the volume of attacks lives, and it is also where you have the most levers. Rate limits, input validation, output filtering, and access control are all inference-time controls, and all of them can ship this week. Retraining cannot.

A third state sits between them and deserves a name: fine-tuning takes an existing model and continues training it on a smaller, targeted dataset. It is cheap enough that ordinary teams do it, which means it is common enough to be a real supply-chain surface. Someone fine-tuning a base model on internal documents has created a new artefact that may contain those documents' contents in its weights.

Where each technique shows up in security tooling

You have been using these systems for years under other names. Mapping the marketing term to the technique is most of what "AI literacy" buys you.

Notice the shape of that list. The mature, high-volume, boring parts of security have used supervised and unsupervised ML for well over a decade, and it works. The genuinely new arrival is the bottom three rows — generative models, which changed what is possible and simultaneously introduced a failure mode (confident fabrication) that the older categories never had.

A supervised classifier in twelve lines

Nothing about this needs a GPU, a framework, or a cloud account. The point is to see the whole loop — data in, model out, prediction — small enough to hold in your head.

# docker-compose.yml — CPU-ONLY, no model download needed for this part
services:
  lab:
    image: python:3.12-slim
    working_dir: /work
    volumes:
      - ./:/work
    command: sh -c "pip install --quiet scikit-learn && python classify.py"

# classify.py — a phishing-ish classifier over toy features.
# Features: [external_sender, has_attachment, urgency_words, link_count]
from sklearn.tree import DecisionTreeClassifier

X = [[1, 1, 3, 4], [1, 0, 4, 6], [0, 0, 0, 1], [0, 1, 0, 2],
     [1, 1, 5, 9], [0, 0, 1, 0], [1, 0, 0, 1], [0, 1, 1, 3]]
y = [1, 1, 0, 0, 1, 0, 0, 0]          # 1 = phishing, 0 = benign

model = DecisionTreeClassifier(max_depth=3, random_state=0).fit(X, y)

# Inference: a message we never trained on.
print(model.predict([[1, 1, 4, 7]]))            # -> [1]
print(model.predict_proba([[1, 1, 4, 7]]))      # -> [[0. 1.]] — "100% confident"
print(model.get_depth(), model.get_n_leaves())  # -> 1 2 — one split separated the classes

Run it and read what happened. fit() was training: it consumed eight labelled examples and produced a fitted object. predict() was inference: it consumed that object plus one new input.

Then look at the last two lines. A single split separated the classes perfectly, so the tree is one level deep, and predict_proba() reports 1.0 — apparent total certainty, coming from a leaf that contains three training rows. That is not the probability the answer is correct; it is the purity of a leaf. The next two pages of this track are about exactly that distinction.

What this track will not teach you, and why

This is a promise, stated up front, so you can decide now whether you are in the right place.

Not covered: eigenvectors and singular value decomposition. They underpin dimensionality reduction and some embedding methods. You will never need them to reason about an AI system's security posture, and no shipping certification objective in this space asks for them.

Not covered: the derivation of backpropagation. You will learn that training adjusts weights to reduce error, and that the adjustment is computed by propagating that error backwards through the network. You will not derive the chain rule. Knowing the derivation changes nothing about how you secure a training pipeline.

Not covered: convex optimisation. Convergence guarantees, duality, KKT conditions — this is the mathematics of why optimisers work. It is genuinely beautiful and it is genuinely irrelevant to defending a deployed model.

Not covered: the attention formula. You will learn what attention does — that a transformer lets every token's representation be influenced by every other token in the context, which is why context windows matter and why anything in the context is effectively addressable by anything else. You will not see the scaled dot-product equation, because writing it down does not help you find an injection point.

The reason for all four exclusions is the same and it is checkable: none of them appears in a shipping certification objective for AI security, and none of them changes a defensive decision you would make. Domain 1 of CY0-001 asks you to compare and contrast AI types and techniques used in cybersecurity — that is conceptual fluency, not derivation. Domain 2 (securing AI systems) carries the heaviest weight, and it is architecture, controls and monitoring.

Self-check before moving on

You are ready for the next rung when you can answer these without looking back up the page.

Where to go next

Work the four remaining rungs of Track C in order. Each one is a single idea done properly.