Labs without Docker
Same objectives as the Docker labs, run entirely through a desktop app. These are an alternative, not a replacement — the Docker bundles are still what you take back to your classroom, and they are what the exam content is built on. Use these if Docker will not cooperate on your machine, if you are short on RAM, or if you want a version you can show students who will never touch a terminal.
Already use NotebookLM? Then you already know this. AnythingLLM is the same idea — ask questions over your own documents — but it runs locally, which is exactly why it can work over logs, incident data, or student records you could never upload to a hosted service. That local, private property is the whole point for security work.
And if you teach log analysis in Splunk or Security Onion, the Day 2 labs are the AI-assisted version of a workflow you already run — same evidence, a different way in.
Building a class around this? Three instructor guides: run a local LLM chat starter in a few lines of commented Python (the simplest possible demo of a chatbot), stand up a secure classroom AI assistant on a spare machine (a private, hardened step beyond NotebookLM), and author your own red-team challenges as a graded CTF.
Set up AnythingLLM — do this once (~5 min)Every lab below assumes it. New to the app? Start here.
- Install it. DownloadAnythingLLM Desktopfor your OS and open it. It is free and runs on macOS, Windows and Linux.
- Pick a local model. On first run it offers an AI provider. Choose the built-in local option (AnythingLLM bundles a runtime — you do not need Ollama or a key). Accept a small model in the 1–3 B range if asked; it downloads once.This is the "nothing leaves your machine" part — no account, no cloud.
- Make a workspace. A workspace is one document set plus its own settings. Create one and name it for the task ("Log analysis"). Each lab tells you which files to put in.
- Find the two controls you will use in every lab:
- Upload — usually a paperclip/upload icon in the workspace, or the workspace's documents panel. Dropped files are chunked and embedded; wait for them to show as ready.
- System prompt — in the workspace settings, a field labelled Prompt. The red-team lab has you paste challenge text here; the analyst labs leave it default.
- Chat. Ask questions in plain English in the main chat box. When documents are attached, the assistant answers over them and can cite which chunk it used.
LM Studio works too for the chat-only labs — load a model, use the chat and its system-message field. AnythingLLM is the better fit where a lab uploads documents.
AnythingLLM Desktop or LM Studio — both bundle a local model runtime, so there is no separate install and nothing leaves your machine. Both are free and run on macOS, Windows and Linux.
Steps below describe what to do and what to look for rather than exact menu paths: both apps change their UI often, and a stale click-path is more confusing than none. If a control is not where you expect, look for the equivalent idea.
Which model to run
Start small. The point of these labs is that a model you can run on a laptop is already useful for classroom work — and a small model makes the failure modes visible, which is exactly what you want students to see. A frontier model papers over weak retrieval; a 3B model does not.
- 1–3B parameters — the default. Fast on CPU, fits in 8 GB RAM, and enough for retrieval, summarisation and triage. This is the class the workshop labs use (
qwen2.5:1.5bandqwen2.5:3b). - 7–8B — noticeably better at multi-step reasoning and at holding a structured output format. Wants 16 GB RAM and patience on CPU.
- Below 1B — useful for showing what "too small" looks like. Tool-calling and JSON output start failing here, which is a Day 4 lesson in itself.
Both apps have a model browser — pick something in the 1–3B range from a current family and you will be fine. Quantised builds (Q4/Q5) trade a little quality for a lot of speed and are the right default on a laptop.
One lab optionally swaps the local model for Anthropic or OpenAI so you can see the gap. It is genuinely useful — and it is also the moment your documents leave your machine, so treat it as the security exercise it is:
- Never paste a key into a shared or cloud lab VM. Those are wiped and re-imaged, other people have used them, and the key is recoverable from disk. Local desktop app only.
- Use a dedicated key with a spend limit, not your production key. These labs cost cents; a leaked key does not.
- Revoke it when the workshop ends. A key that outlives its purpose is just an unowned credential.
- Assume everything you send — including every retrieved chunk — is now off your machine and subject to the provider's retention policy. If your documents are real, this is a decision for whoever owns that data, not for you at a workshop.
The comparison is entirely optional. Every other lab on this page runs fully local, and nothing here requires you to spend money.
Day 1
Build a RAG workspace over a document set
Stand up a working retrieval-augmented generation pipeline and see grounded answers cite their sources.
Break your RAG pipeline on purpose
Make RAG failure modes measurable: retrieval miss, hallucination under low similarity, and indirect prompt injection through a poisoned document.
Tokens: count them, break them, budget them
See text become tokens, understand why token counts differ by content type and model, and connect tokens to both cost and the context window.
Sampling parameters and a model A/B
Turn "the model felt random / slow / dumb" into numbers you can defend: determinism versus temperature, and size versus speed on your own hardware.
Day 2
Get answers out of a log file
Install a local AI assistant, point it at real security logs, and pull findings out of them in plain English — the core classroom-ready skill.
Triage a SOC alert queue
Work a realistic alert queue the way a junior analyst does: separate noise from signal, correlate related alerts, and decide what to escalate first.
Evaluate a host from its configuration
Read a host configuration snapshot and find the misconfigurations that let an attacker persist — the hardening review a sysadmin does.
When the logs fight back
See indirect prompt injection first-hand: attacker-controlled text inside your data hijacking the AI that reads it — the core Day 2 security idea, from the analyst's chair.
Red-team an AI assistant
Play the attacker: break an AI assistant's rules through chat alone — extract a secret, leak its system prompt, defeat its guard. The offensive side of everything Day 2 teaches defensively.
Day 3
Find and redact PII with AI
Use a local AI assistant to locate personal data across structured and unstructured files and produce a redacted version — the data-minimization skill behind every privacy regime.
Red-team a data-protection assistant
Extract protected data from an assistant that guards it only with a prompt — proving that a data-handling rule written into the prompt is not a control.
Day 4
AI-assisted detection engineering
Use an AI assistant to draft detection rules for a real intrusion, then validate them — the generate → validate → repair loop that makes AI a detection force-multiplier without replacing judgment.
Red-team the detection
Reason about how an attacker evades naive detections and how to harden each — the offensive angle that produces durable, behavior-based rules.
Small model vs frontier model, same task
Judge honestly where a small local model is good enough and where a frontier model earns its cost and its data-sharing trade-off — the right-sizing call at the heart of Day 4.
The Docker labs run with the network disconnected and every image digest-pinned, which is how you prove to a security team that nothing left the building. A desktop app is local too, but you are trusting the vendor's word rather than demonstrating it. If that distinction matters in your environment, run the Docker path at least once.