We Teach Security Backwards: I Put AI Red-Teaming on Day 2 and Never Got There
I designed a two-day workshop with AI red-teaming as a full module, not a closing talk. We finished three of eight sessions. The classics ate both days.
We treat the security of AI systems as a specialist topic, something you get to after years of “the fundamentals.” I spent a weekend arguing otherwise: a two-day workshop where AI red-teaming was a full hands-on module instead of a closing talk. We got through a third of the plan, and why it happened taught me more than the argument I walked in with.
The gap nobody designs the curriculum around#
Walk through almost any introductory cybersecurity syllabus and you’ll find the same spine: cryptography, networking, the OWASP Top 10, maybe some malware. It’s a good spine. It’s also the spine we’ve taught for fifteen years, and it stops exactly where the students’ actual world begins.
Because the applications these students use, build side-projects on, and will be hired to work on are increasingly LLM-powered. Prompt injection, insecure output handling, and excessive agency aren’t specialist topics to them. They’re the security properties of the tools already in their hands. Yet we file AI security under “later,” if we file it at all.
So when KSIT invited me to run a two-day workshop for their third- and fourth-year CS students, I took it as a chance to test the argument in a real room, and made one deliberate choice in the design: AI red-teaming wouldn’t be a bonus talk at the end. It would sit on Day 2 as a full module, with its own labs, right next to the classics.
What I planned, and what actually ran#
Eight sessions across two days, browser-first, roughly two-thirds hands-on. Day 1 was the foundation: cryptography you can see with CyberChef, reading credentials off a packet capture in Wireshark, then the OWASP Top 10 against a deliberately vulnerable app, then turning each bug found into a fix and threat-modeling the app they’d just broken. Day 2 was the argument: red-teaming a live LLM chatbot, threat-modeling a GenAI feature against real incident data, hardening, and a scored Capture-the-Flag drawing on everything.
We finished session three.
Fifty-plus students, two full days, and we reached the end of the web-hacking labs. The threat-modeling exercise that closes Day 1 never ran. Neither did the AI module or the CTF. The material I had designed the entire workshop around, the part meant to make the point, never got taught at all.
The spine always wins#
The reason it happened surprised me, and I think it matters well beyond one workshop.
Nobody in that room deprioritised AI security. I had scheduled it on purpose, defended its slot in the agenda, and built the labs for it. It still didn’t happen.
That is not a story about one over-ambitious plan. It’s the mechanism. Nobody in security education decides AI security is unimportant. They schedule it last, the fundamentals run long, and last never arrives. Every hour of cryptography and packet analysis is defensible on its own terms. The spine expands to fill whatever time you give it, and the newest material is always what gets cut, because it’s what sits at the end.
I designed a workshop specifically to escape that ordering. It made no difference.
Hands-on time is the constraint nobody budgets for#
If you design a workshop like this, this is the part to budget for.
Fifty-plus students on shared machines changes the arithmetic. Every lab step has to land for the whole room before you move. One environment that won’t start isn’t one student’s problem; it’s five minutes off the clock for everyone, and it compounds session over session in one direction only. Lecture time is predictable. Hands-on time is not, and hands-on time is the whole reason the format works.
That forces a choice partway through Day 1. Push the room through the web labs at the pace the schedule assumes, or let students finish exploiting and fixing what they started and give up the back half of the agenda.
I chose the second, and I’d choose it again. A student who has personally broken a live application and then closed the hole keeps something. A student who watched me demo four more topics on a projector does not. Anyone who tells you they reliably deliver eight hands-on sessions in two days is running a lecture with labs attached.
But that trade gets paid for somewhere, and the bill lands at the end of the agenda. My own workshop had just proved the argument I came to make.
So the fix isn’t “add AI security to the end.” Decide, before the room fills, which sessions the workshop cannot do without. If two days realistically carry three hands-on sessions, the honest question is which three. On this evidence I’d move the AI module to Day 1, straight after the web labs, and let the material that slips be the material every other workshop already covers.
I’ve open-sourced the material#
The full workshop is public: slides, student handbooks, the deliberately vulnerable lab apps, the OWASP Juice Shop architecture breakdown, and a heavily curated reading list for every topic. Including the Day 2 material that never ran.
github.com/Antak108/KSIT_workshop
What’s deliberately left out: the answer keys, the CTF flags, and the facilitator solutions. It’s teaching material, not a solutions dump. If you run security education, take it, adapt it, and put AI red-teaming somewhere it will actually be reached.
Where I’d take this next#
The AI module deserves to go deeper than a single session anyway: the Five-Zone Method for threat-modeling agents, the MAESTRO framework, and the incident data rather than the sci-fi failure modes.
But the sequencing lesson comes first. AI security goes in the core of the syllabus, in the first hours, not the last. I’ll run this again with the order changed, and I’ll write up whether it works.
I write about AI/ML security and threat modeling, the grounded version, read from the research rather than the marketing. If that’s your thing, subscribe to the newsletter.