Free, open training for security teams. Six tracks: the first builds an agentic system, and the other five each take one part of a security organisation — architecture and infrastructure, application security, offensive security, the SOC and governance — to show you how that work changes when agents do it. You also learn how to secure the AI itself. Every lesson runs on your own computer, in the AI tool you already use.
Breakout time — how long it takes an attacker to get from first access to moving sideways — is now 29 minutes. The fastest on record is 27 seconds. Now look at how most security work is done: architecture reviewed every few months, alerts read one at a time, controls checked once a year. Attackers are already using AI to go faster. You cannot close that gap by reading faster — you have to change how the work gets done.
Most teams can name the risk. Far fewer have had the chance to learn how to do the work differently, and capability thins as organisations get smaller — then thins again for the newest controls. Buying a product does not change how a team works. Learning to do the work a new way does, and that is what each track teaches.
Teaching the technique is the easy half. Changing how a team works means answering three questions, in order, and every lesson here answers all three — Day 0, why this is worth doing at all; Day 1, the thing you build; and Day 2, the number that tells you next quarter that it still works.
What goes wrong if you do nothing, and why this is worth an afternoon.
The concrete thing you stand up — a control, a pipeline stage, a detection.
The number that says it worked, and keeps saying so afterwards.
Getting that work funded is the real challenge, and it is hardest in budget-constrained organisations — the ones that cannot buy the capability and are not going to be sold it either. A curriculum that stops at the technique leaves you with nothing to take to the person holding the budget. This one has to carry all three days, on every lesson.
It is written by practitioners who ship this under audit — senior people working in regulated industries, where a control has to satisfy an auditor as well as an attacker. The material and the building blocks are updated continuously, so they keep pace with what those practitioners are actually seeing.
These are not six subjects. The first track builds the agentic system the rest are about, so start there whatever your job is. The other five are the parts a security organisation is actually made of — architecture and infrastructure, application security, offensive security, the SOC and governance — and each one teaches you how that work changes when agents do it. After that, take the one that matches your job. Nobody needs all six. A0.0 sets your machine up and the introduction says who each track is for.
The thing the other five tracks are about. Set your machine up, then build CyberTravels end to end — the loop, MCP tools, identity and delegation, memory, agent-to-agent, spans and an audit trail. Whatever your job, it is hard to secure an agent you have never built.
Everyone, first · the system the other five tracks are about
What changes in a design review. One reference architecture for agentic systems, every risk that attaches to a part of it, and the identity, ingress and runtime controls that close them — so a review ends with a list of risks and owners instead of an opinion.
Architecture and infrastructure security · architects · engineers shipping an agentic feature
What changes in an AppSec pipeline when agents write the code. Threat model, two-pass scan, deduplication, reachability, a proof in a sandbox, supply chain, and a fix that has to show evidence before it merges — before and after deploy.
Application security · AppSec and product security engineers · penetration testers
What changes in a red team. One authorised, scoped lifecycle against your own estate, from ingestion and elicitation to containment, forensics and governance — and why a finding has to reproduce before it counts.
Offensive security and evaluation · red team operators · AI security researchers
What changes in a SOC, across five intervals of one clock. Detection and response when the analyst is directing agents instead of reading alerts one at a time, and when the thing being investigated is itself an agent.
Security operations · SOC analysts · detection engineers · incident responders
What changes in GRC and the CISO office. Framework controls become numbers somebody can actually compute, mapped out to the rules that apply to you, in a programme ordered to produce control coverage rather than demos.
Governance, risk and compliance · risk owners · the CISO office
16 chapters, 149 lessons, and every tool named in them is open source.
Working through it alone, or running it for other people? There is a course guide for each of the six tracks — every lesson's risk, control and measure, the skill it runs and what that skill prints, the pitfalls, and a quick check. Track A's is the place to start, whatever your job is.
You do not learn a control by reading about it. Every lesson runs a real agent skill whose source you can read — as a script, or inside the agent CLI you already use — and maps what it did back to the open frameworks your organisation already reports against. Then you change something and run it again, and watch the number move — which is the part that builds the instinct. You do not leave with notes. You leave with a control working, a pipeline stage running or a detection written, and the number that tells you later whether it is still doing its job. No install, no GPU, no licence.
The job isn't doing the work by hand anymore — it's directing work you have to be able to trust, doubt and prove.
