AI Red Team Lab Setup 2026: Build Your Range in One Hour | Offensive AI Operator Course Day 0 of 30

Ninety percent of people who quit a hands-on security course quit on setup — not on the hard material, on the lab that wouldn’t build. So before we touch a single attack, we’re going to build your AI red team lab properly, pin every moving part so it behaves the same in six months as it does today, and end with one command that green-checks the whole thing. Get this hour right and the next thirty days just work. Skip it, or rush it, and you’ll spend Day 1 debugging Docker instead of learning to break models. Let’s build the range.

Welcome to the setup module for the Offensive AI Operator. This is Day 0 — un-numbered, because it’s not a lesson, it’s the workbench every lesson sits on. By the end you’ll have a complete, pinned AI red team lab and a green verify.sh. Then, on Day 1, we start mapping. If you’ve built a traditional lab before — our legal home-lab guide covers that world — this is the AI-specific version, and the differences matter.

Why the AI red team lab is built this way

Before the commands, spend two minutes on the why, because it explains every choice you’re about to make and it’s the difference between a lab you understand and a lab you copy-pasted. Three decisions define this range, and each one is a deliberate answer to a way AI labs usually rot.

Decision one — everything runs locally

You could point this course at a paid API and learn plenty. We don’t, for three reasons that all matter. Cost: firing thousands of attack iterations at a metered API turns a course into a bill. Determinism: a hosted model updates on someone else’s schedule, so the exploit you learn on Tuesday can vanish on Thursday when the vendor ships a new version — I’ll show you that failure mode later and it’s maddening. And terms of service: hammering a commercial endpoint with jailbreak payloads is a fast way to get an account banned, and it blurs the ethical line this course is careful to keep sharp. Local open models via Ollama solve all three at once — free, frozen, and entirely yours to abuse.

There’s a fourth reason I’ll say plainly because it’s easy to miss: running the model yourself means you can see inside. When the target is somebody’s API, the model is a black box — you send text, you get text, and everything in between is hidden. When you host it, you control the temperature, you can watch resource usage spike when a payload makes the model work harder, and later in the course you can inspect what the model actually received after the app assembled its prompt. That visibility turns guesswork into observation. A hosted API teaches you to attack blind; a local range teaches you to attack with the lights on, and the instincts you build with the lights on make you far sharper when you’re eventually back in the dark against a real target.

Decision two — everything is pinned

“Pinned” is the word you’ll hear me repeat more than any other. A lab that says “install the latest Kali” or “pull the model” is a lab that behaves differently for two students on the same day and differently for you next month. We pin the host version, the container tags, and — most importantly — the exact model digest, not the floating latest tag. When you build your own labs after this course, pinning is the single discipline that separates a range you can trust from a range that lies to you. A result you can’t reproduce is not a result.

Let me make the failure concrete so the discipline sticks. Imagine you skip the pin and just ollama pull llama3.1:8b whenever. You spend Day 9 building a jailbreak that works beautifully. Two weeks later you come back to demonstrate it and it flatly fails — and you have no idea why, because you changed nothing you can see. What changed is that latest quietly pointed at an updated build with different behaviour, and the model you built your attack against no longer exists on your disk. Now multiply that across thirty days and every technique you learned, and you understand why an unpinned AI lab is worse than useless: it teaches you things that stop being true and gives you no way to tell which. The digest you record in Step 3 is a promise that the target you attack today is the same target you can re-attack in a month. Keep that promise and the whole course stays reproducible.

Decision three — the cloud account is real but caged

The cloud days need a real account — you can’t learn IAM escalation against a simulator that doesn’t behave like AWS. So we use a genuine free-tier account, but we cage it: read-mostly usage, a hard billing alarm wired before anything else, and cleanup after each cloud day. The goal is to touch real cloud primitives without ever touching a real bill or a real third party. That balance — real enough to learn, caged enough to be safe — is the whole philosophy of this range in miniature.

A word on hardware, before you hit a wall

The one resource that decides whether this range runs smoothly is RAM, and it’s worth being honest about it now rather than watching you discover it mid-build. An 8B model wants roughly 8 GB of memory to itself while it’s loaded, and the Docker stack wants its own share on top. On a 16 GB machine you’re comfortable — model loaded, containers up, Burp open, room to spare. On 8 GB you can still do the course, but you’ll run one thing at a time and lean on a smaller quantised model, and you’ll want to stop the app containers when you’re only working with the model directly. Below that, you’ll fight the machine more than the material. None of this needs a powerful GPU — these models run on CPU, just slower — so don’t let the absence of a graphics card stop you. Plan the memory, ignore the GPU, and the range behaves. If your machine is genuinely too small, that’s the one place a cheap cloud VM for the duration of the course is a reasonable spend, and it’s the only spend this course asks of you.

The build: seven steps to a hot range

Work through these in order. Each step ends in a state you can confirm before moving on — don’t push forward on faith, because a silent failure early makes a confusing failure late. Total time is about an hour, most of it waiting on downloads.

Step 1 — Prepare the host

Kali 2026.2 or Ubuntu 24.04, updated once, with the handful of tools the range assumes. We pin to these two because they’re what verify.sh expects; another distro may work but you’re on your own for paths.

Step 2 — Install and sanity-check Docker

Everything except the models runs in Docker, so a healthy Docker daemon is non-negotiable. Install it, add yourself to the docker group so you’re not sudo-ing every command, then log out and back in for the group to take effect.

Step 3 — Install Ollama and pin the models

This is the AI-specific heart of the range. Install Ollama, then pull the two models we use by digest, not by the floating tag. The commands below pull the tags; the pinning discipline is that you record the digest verify.sh reports and never re-pull latest over the top of it.

 $ ollama list
 NAME             ID            SIZE     MODIFIED
 llama3.1:8b      42182419e950  4.7 GB   just now   ← record this ID
 qwen2.5:7b       845dbda0ea48  4.4 GB   just now   ← and this one

 # THE ID IS THE PIN. If it ever changes, your labs changed too.
  

Step 4 — Stand up the vulnerable LLM app

The course ships a deliberately vulnerable LLM application, se-vuln-llm, that every attack day targets. It’s not a hosted service you log into — it’s code you clone from the course repo and run entirely on your own machine, so the target you attack is one you own outright. Clone the range repo, bring it up with the pinned compose file, and confirm it answers.

Don’t take a JSON reply as “done” — take it as “the wiring is alive,” which isn’t the same thing. Before you move on, look at the container health directly, because an app that starts and an app that’s healthy are different states, and the gap between them is where a lot of Day 1 frustration hides. The compose file ships a healthcheck for exactly this reason; read it.

 $ docker compose ps
 NAME           IMAGE              STATUS                 PORTS
 se-vuln-llm    oaio/vuln:day1     Up 40s (healthy)       0.0.0.0:8080->8080
 se-vectordb    oaio/qdrant:pin    Up 40s (healthy)       0.0.0.0:6333->6333
 se-proxy       oaio/gateway:pin   Up 40s (healthy)       0.0.0.0:8080->8080
  ── "(healthy)" on every row is the state you want, not just "Up" ──
  

Notice there’s more than one container here. The vulnerable app itself is only part of the range — there’s a vector database (you’ll poison it on Day 11) and a small gateway (it shapes traffic you’ll inspect in Burp). You don’t need to understand them yet; you just need all three showing (healthy) before you continue. If one is stuck on starting for more than a minute, that’s a signal, and the failure-states section below tells you which one to look at.

Step 5 — Wire Burp as the proxy

You’ll live in Burp for the recon days, so set it up now. Point your browser at Burp’s proxy, install Burp’s CA cert so HTTPS doesn’t scream at you, and confirm you can see the app’s traffic. If you’ve proxied a normal web app before, this is identical — the app just happens to talk to a model behind the scenes.

Here’s the one AI-specific thing to check while you’re in here, and it pays off on Day 1: send a chat message through the app with intercept on, and confirm you can see your message sitting in the request body before it reaches the model endpoint. That’s the moment that matters, because the entire recon phase depends on being able to watch — and modify — text on its way into the context window. If your message shows up in the intercepted request as plain, editable JSON, your proxy is positioned exactly where you need it. If it doesn’t, you’re either not proxying the right traffic or the app is doing something client-side worth noting. Either way, better to learn it now during setup than mid-lab tomorrow.

Step 6 — Create a safe, budget-capped cloud account

The cloud days (19–21, 26) need a real AWS free-tier account. Before you create a single resource, wire a billing alarm — this is the step people skip and regret. Set a low threshold, confirm the alarm, and only then proceed. Read-mostly is the rule: you’ll build deliberately weak configurations in your own account and attack them, then tear them down.

Set the billing alarm low enough that it fires before anything real happens — a few dollars, not fifty. The point isn’t to catch a catastrophe, it’s to catch the small mistake early: a resource you forgot to stop, a service that isn’t as free-tier as you assumed. Alongside the alarm, get in the habit from day one of tearing down what you build. Each cloud day ends with a teardown, and the reason is the same reason a professional never leaves a client’s account dirty — an orphaned resource isn’t just a cost, it’s an unmonitored piece of attack surface you created and walked away from. Treat your own lab account with the discipline you’d owe a client’s, and the discipline is there when it counts.

Step 7 — Run verify.sh

The range ships a verification script that checks every component in one shot. This is your green light, and the rule for the whole course is simple: if verify.sh isn’t all-green, you don’t start the day. It saves you from the worst outcome in a self-paced course — debugging your environment while thinking you’re debugging the lesson.

The one command that proves your AI red team lab works

Run it from the range directory. It checks host tools, the Docker daemon, both pinned models and their digests, the vulnerable app’s reachability, and the app-to-Ollama wiring. Read the output top to bottom — a single red line is a reason to stop and fix, not to push on and hope.

 $ ./verify.sh
 [PASS] host        Ubuntu 24.04 detected
 [PASS] docker      daemon reachable, non-root OK
 [PASS] python      3.11 venv active
 [PASS] ollama      service up
 [PASS] model       llama3.1:8b  digest 42182419e950  (pinned)
 [PASS] model       qwen2.5:7b   digest 845dbda0ea48  (pinned)
 [PASS] app         se-vuln-llm reachable on :8080
 [PASS] wiring      app → ollama round-trip OK
 ────────────────────────────────────────────────
 RANGE STATUS: ALL PASS — you are cleared for Day 1
  

That’s it — the range is hot. Every one of the next thirty days assumes this exact state, which is why we built it once, carefully, instead of improvising a target per lesson. Keep the range directory; keep the digests you recorded; keep this screenshot.

Take a second to understand what those eight green lines are actually telling you, because verify.sh isn’t magic — it’s the same handful of confirmations you’d otherwise do by hand, bundled so you can’t forget one. The host check catches the wrong-distro problem before it produces mysterious path errors three steps later. The Docker check confirms not just that Docker exists but that you can drive it without sudo, which is the single most common setup snag. The two model checks are the ones that matter most for this course specifically: they confirm the models are present and print their digests, so you can compare against your pin and catch a silent version drift the moment it happens. The app and wiring checks confirm the two hardest-to-diagnose failures — a container that started but isn’t serving, and an app that’s serving but can’t reach the model. Every one of these is a failure I’ve watched cost someone an evening. The script turns an evening into a line of output.

Here’s the habit I want you to build around it: run verify.sh at the start of every session, not just today. It takes three seconds and it answers the question that silently wrecks self-paced learning — “is my environment actually in the state I think it’s in?” Nine times out of ten it’s green and you move on. The tenth time, it hands you the exact red line instead of letting you burn forty minutes attacking a target that was never up. Cheap insurance, every single day.