Your AI security practice notebook

Practice resource. The six Parts follow the slides in order; this notebook groups lab practice into six sections ("lessons"). Each section maps to a Part and its slides:

Notebook section	Part and slides	Labs
Lesson 1	Part 1, slides 30–33	01
Lesson 2	Part 1, slides 14 and 26–27; Part 2, slide 44	03, 13, 08
Lesson 3	Part 2, slides 42–46	04, 05, 11
Lesson 4	Part 3, slides 51–56; Part 4, slides 10–17	07, 08, 09, 10, 14
Lesson 5	Part 5, slides 24–32	02, 06
Lesson 6	Part 6, slide 45 (the recovery-assistant page is optional)	12
Group sheet	Part 6, slides 37–38 and 41	—

Use this alongside the labs. One page of notes per section is enough. Work with a partner, predict before you change a control and swap who operates. Keep the full lab tab open if you want to retain its state. Copy notes before leaving; the site does not save them automatically.

36 worked cases · All seventeen experiments

All sections are self-study; no class minutes are attached. Each core route selects a few experiments. Use the other cases for questions or further practice; do not race through every control.

What makes an explanation convincing?

Use these questions when reviewing your partner’s notes. A sound explanation connects the mechanism to an observation and a bounded security decision; a score alone is insufficient.

For a short pair task, explain one changed factor, one observation and one limit. In the final recommendation, connect all six criteria. These are formative feedback criteria, not a formal grading scheme.

Lesson 1 · Teach a login-alert model

Worked example. With x=0.5, w=1 and b=0, the score is 0.5. Increasing b to 0.2 makes it 0.7. A new input uses the current weights; training changes them.

Open the model. The lecturer demonstrates it on Parts 1–3 slide 33; repeat it at your own pace. Compare a line and a network. Then choose clean labels, 12 units, reset and train exactly 1,000 updates once. Record validation MSE and one sentence explaining the fit. Do not reveal the held-out test yet.

Keep the network fixed. Compare thresholds 0.15 and 0.70, then the 0.35 middle reference. Record false alerts, misses and queue size. The requirement is at most 30 reviews and at most 2 misses among 80 examples. Report a conflict if none works.

Explain: what changed, and what stayed fixed? Leave the held-out test sealed until your choices are recorded. Explain training (changes parameters), validation (compares choices) and test (kept aside until your choices are recorded). Then reveal a recorded candidate once; revealing it locks tuning for that run.

Paper alternative. Alerts are (score, label): (0.20, normal), (0.40, priority), (0.60, normal), (0.80, priority). Circle scores ≥0.50, then ≥0.30. Count true positives, false positives, false negatives and true negatives. This practises routing; it does not replace hands-on training or use the same 80-example dataset.

Extra worked cases: E01–E06.

Lesson 2 · Build a phishing detector

Worked example. Features mismatch=0.8 and pressure=0.7, weights 2 and 2, bias −2 give z=1. The sigmoid score is approximately 0.73. A threshold of 0.50 sends it to review.

Open the phishing lab. Reset, then train 500 updates once. Inspect one correctly flagged message and one mistake. Switch from validation messages to the new campaign without training again.

Core transfer, self-study: learn from image pixels. Look at the 8×8 rasters: each pixel is one tiny square with a brightness value. R means review, N means no review. Predict which pixels distinguish the marks. Keep zero label edits, train both 500 updates and inspect one weight. Explain one result and one security fact absent from the pixels. Both copies agree because their labels match. Stop after guide step 3; the later steps are further practice.

Optional S1 feature edit: keep threshold 0.50; raise only mismatch to 0.90, predict, then restore S1 by selecting S3 and S1. This edits the supplied feature, not message text. Image poisoning/evasion are also further practice or a transfer from lesson 4.

Optional: compare a manual weight edit (changes the function and restarts the update count) with a threshold edit (changes routing only). Finish the handover before adding these experiments.

Pair handover: “The model sees ___. It missed/flagged ___ because ___. I would inspect ___.”

Extra worked cases: E07–E12. The frozen-detector sandbox expands the evasion comparison.

Image example: in the phishing lab choose Images. Predict from the two identical login crops, then reveal the addresses. Explain which information was outside the image and why the numeric model is not a vision model.

Lesson 3 · Investigate behaviour and workload

Open the anomaly lab. Compare 95 MB/min with the office and backup baselines. Keep the event fixed while switching the reference. Reveal context only after predicting the result. Then inspect the slow unauthorised transfer at 12 MB/min.

Traffic evidence: switch the anomaly lab to Traffic evidence. Read the one-minute flow record. Derive 95 MB/min from 95,000,000 bytes in 60 seconds. Compare the next flow at the same volume, then reveal process/approval evidence. Returning to Volume keeps that selected event.

Worked distance: office mean 10, spread about 1.225, new event 12 MB/min gives |12−10| / 1.225 ≈ 1.6, below cutoff 3. Use the supplied spread; you do not need to derive it.

Record one false alarm and one miss you can explain. Name a process, destination or authorisation record that would distinguish a legitimate backup from data theft.

Malware mini-case: A is a compressed updater from the managed software channel; B is invoice_7731.pdf.exe, a packed attachment from the exampIe.com sender that connects to the unfamiliar destination 203.0.113.45. Both have high byte entropy. Request one independent record to investigate the difference. These are descriptions, not files to execute.

Train the file detector, self-study comparison. Run entropy-only → train → compare F1/F2, then both features → retrain → compare F2/F4. Predict whether matching inputs get matching scores, then explain the revealed contexts. Record one error and one missing observation. F3/F5/F6 are further practice; no files are executed.

Open the analyst queue. Start with 1,000 events, 20 attacks, recall 90%, false-positive rate 5% and 50 review slots. Work the numbers together, then change total events to 2,000 while keeping the attack count and rates fixed.

Calculation help: TP = attacks × recall. FP = benign events × false-positive rate. Queue = TP + FP. Precision = TP / queue. A calculator is welcome. If stuck, ask for the TP and FP counts and focus on interpretation.

Can these totals establish which attacks survive reviewing only the top 50? What additional evaluation would Mina need?

Check yourself: training versus inference; one model error; one observation needed before acting.

Extra worked cases: E13–E18.

Lesson 4 · Challenge the model

Before changing a control: predict what will happen. Write what you will change, what you will keep fixed and which result you will read. Afterwards, compare the result with your prediction. For an attacker example, name what the attacker would actually need access to.

Open the dedicated poisoning comparison. The same architecture, initial seed, update budget and clean evaluation reference are used for both models. Start count 6, shift 0.9, threshold 0.35. Predict which scores will move down, then train both 1,000 updates. Compare three labels, then restore trusted labels and retrain.

Explain: how can the optimiser learn the wrong lesson successfully? Who can edit accepted labels, and which provenance makes restoration trustworthy? The reference is course data, not an attack benchmark.

Then make shorter predictions:

• Evasion: change one represented input; confirm weights stay frozen. Threshold comparisons are further practice.
• Leakage: predict the row split, then hold out campaigns. Individual card moves are further practice.
• Drift concept: read the timeline and distinguish changed normal activity from accepting an incident into the baseline.

Core transfer, self-study: learn from traffic windows. Both schedules move 360 MB. Compare their order; return to the review case. Reset; use zero label edits and threshold 0.50. Train both 500 updates. Change nine review labels to no review; inspect R→N, then retrain both. Reschedule by one minute without retraining. Restore input and explain poisoning versus evasion. Optionally, set label edits to zero and retrain for recovery.

Predict and explain each row before you read the scores. Drift/baseline controls remain an optional comparison.

Record one changed surface and the observation that distinguishes it. The complete set of slider edits and partitions is optional practice. E19–E24 provide six concrete cases.

Optional extension: all 13 targetable labels; shifts 0.3/.9; a full drift/reference matrix; individual campaign-card movements. Compare one factor at a time. The original login model also retains sparse/noisy data and coverage-gap experiments.

Lesson 5 · Inspect the assistant’s boundaries

Follow one reply: the model extends “Please verify your” with a text piece such as “identity”, then chooses another piece using the longer text. These pieces are tokens; generating them does not retrain the model. The application can first look up an allowed recovery procedure and add it to the question: this is RAG. Draw question → allowed guidance → draft → separate ticket-service check. Which step reads, and which step can act?

Open the assistant walkthrough. The lecturer demonstrates it on Parts 4–6 slide 32; repeat it at your own pace. Run the ordinary Analyst case. Then choose the injected ticket as Analyst with approval absent, predict and run both designs; record one difference. Then run the customer and permitted staff-approval cases. Compare context documents, scripted proposal, decision and simulated effect. This is a deterministic teaching simulation; no language model is running.

Open the approval rule. Try all checks true, approval absent, then approval absent plus injected text. Record one allow and two deny outcomes.

Draw just five boxes: ticket text → retrieved context → proposal → action check → actual effect. Place one control before context and one before an action. For each, name what it checks, the enforcing component and the useful work that can continue.

Partner challenge: “Would this still help if the model ignored its instructions?”

Extra worked cases: E25–E30. The assistant dropdown also includes retrieved-page instructions, forged approval, forged policy and urgency pressure. All proposals remain explicitly scripted.

Lesson 6 · Investigate and brief the owner

Records: 16:10:02 closure proposal; 16:10:03 approval lookup unavailable; 16:10:04 tool request logged, response missing; 16:11 UI shows resolved. These are scenario times.

Open the incident investigation. In the core route, investigate Case A. Begin with insufficient evidence; request ticket history and the correlated operation result before choosing a cause. Add the approval record to assess authority. Record the decisive actor/state/operation observation, then compare Case B or C. Solving all three cases is further practice.

Worked containment: suspend automatic closure while staff handle recovery and preserve relevant evidence, with the recovery-service owner coordinating. You supply one explanation, one alternative and the exact record that could distinguish them. Reconcile authoritative state before retrying an uncertain action.

Optional · your recovery-assistant page

Optional and untimed; work alone or in a small group. The template is deliberately only partly filled in. Complete the missing entries in bullets. Reuse the two controls you placed in lesson 5. Different decisions are acceptable when the conditions and evidence are clear.

What you are deciding: may an analyst use the assistant to draft recovery replies, and may it close tickets automatically? Decide separately. Recommendation: do not use yet / fix it first / try it with clear limits: ___. Next action and evidence needed: ___.

Proposed operating conditions (keep or correct): recovery-service owner can stop automatic closure if an unapproved state change or uncertain operation is observed; retain relevant correlated records and reconcile affected tickets. Staffed manual recovery continues. Restore automatic closure only after the relevant boundary is checked, affected state reconciled and an owner reviews the evidence. State one concrete check you would require before restoration: ___.

Suggested order: scope/read, closure control and denial check, unavailable-service check, decision/owner/next action. Write one defensible explanation before polishing. Selecting an alternative scoring-only case is an optional extension after the core activity.

If you work with others, exchange pages. Give one strength and one concrete correction. Check the AI mechanism, security boundary, evidence and recovery. Mark a claim as proposed or conditional if its evidence has not been collected.

Briefing (optional): use “We recommend … because we observed … . This could still go wrong if … . Before using it, … must check … .”

Check yourself: name one control, the exact evidence of its effect and one change that would invalidate that evidence.

Extra worked cases: E31–E36.

Group sheet · hospital triage

For the group exercise on Parts 4–6 slides 37–38 (groups of four, 15 minutes) and the labelling step on slide 41.

1. Sketch the data flows. Mark the trust boundaries and who controls each input.
2. Identify four threats and map them to OWASP or ATLAS (slides 30 and 35).
3. Propose a control for each. Which actions need human approval?
4. Escalate one residual risk to the chief information security officer (CISO).

Data flows and trust boundaries (sketch): ___

Residual risk escalated to the CISO, and why it remains: ___

Transfer across data modalities

Open the visual modality guide. It connects logs/tables, text, images, time series/event order, files/code, graphs, audio and video. The combined-evidence case asks whether a screenshot and a voice transcript copied from one ticket count as independent approval. The four feedback checks and three new trainable audio/video/graph labs are further practice. Work at your own pace; they add no tasks to the lectures.

If you want more practice

Try a different threshold without changing weights; explain a new-campaign error before retraining; compare baseline choices; or design a positive control for a prohibited-action check. Complete one solid explanation before adding experiments. No real organisational data, credentials, malware execution or external model account is needed.

Optional media and graph training: use the same learning loop

Audio: train clean, poison nine labels/retrain, then shift four samples. Hear the tone and compare waveform/spectrum: frequency and energy stay fixed; the phase-sensitive model can change its score.

Video: train on four ordered frames, poison nine labels/retrain, then shift the loop start by one frame. Every frame remains; its weight position changes. Play both clips and explain the difference between the displayed sequence and independent export/approval evidence.

Graphs: train on six-node adjacency matrices, poison nine labels/retrain, then reorder nodes by three. Trace A→D→E→F in both drawings: identities and connections are unchanged; a flat matrix learner is brittle to serialisation.

For one chosen lab record: original clean score ___; original poisoned score ___; edited-input clean/poisoned scores ___; invariant ___; updates still 500 ___; after restoring trusted labels the copies agree ___. A poisoning effect and an evasion effect need not combine monotonically. The audio example makes this visible.