Journal.

Stay up to date with the latest news and resources from the Ryvane team.

Most AI security curricula split into two tracks: red team and blue team. The red team learns to attack, the blue team learns to defend. The split is intuitive — that's how the rest of security education works.

We don't do it that way at Ryvane Academy. There's one track, and it's offensive. Defense is taught only as a consequence of having broken something. The argument for this structure is the most contested decision we've made, and it's the one we get asked about most. Here's why.

What "defense first" actually teaches

A defense-first curriculum has to start somewhere. Usually that somewhere is a list: a taxonomy of known attacks, mitigations for each, a recommended posture. The list is fine. The problem is what comes with it.

A student who learns the list before they've broken anything internalises three things that are almost always wrong:

  1. That the threat model in the textbook is the real one. The real threat model is whatever is cheapest for an attacker against your specific deployment. Textbooks generalise; deployments are specific.
  2. That mitigations work the way the documentation says they do. Most mitigations in production are partial. The "rate limiting" you ship is bypassed by IP rotation; the "input sanitiser" misses Unicode normalisation; the "guard model" can be talked around in seven turns.
  3. That defense is a checklist. It isn't. It's a hypothesis about an adversary's behaviour, and hypotheses have to be tested. The test is offense.

You can fix these later. But you have to spend a year unlearning them.

What "offense first" actually teaches

When a student's first task is to break a thing, they learn something different in the same week: the texture of an actual attack.

The texture matters. Real attacks aren't clean. The first three exploits you write don't work. The fourth works in a way you didn't expect — it succeeds because of a bug in the framework, not the model, and that bug has nothing to do with the threat model you started with. You write up the bug, and the act of writing exposes that the "mitigation" the team had in place was checking the wrong layer.

The student who's been through this is the student who, when they later read a defence checklist, can immediately tell which items are theatre. They've sat with the actual mechanics. They know what an attack costs an attacker. They know what a defence costs a defender, and which defences attackers route around in their sleep.

The most expensive misconception we see in industry hires is that they think defense is a known science. Offense teaches them, faster than anything else, that it isn't.

What this looks like in the cohort

Twelve weeks. Three phases.

Encounter. Two weeks. Each student picks a production agent framework — not a toy, a thing that's actually shipped to users — and reads it until they can describe how the prompt is built, what the tool layer looks like, where the trust boundaries are, and where the framework's authors thought adversaries would come from. There's no offence yet. The deliverable is a written threat model.

Engage. Six weeks. Students break the framework they picked. The exit bar is one PoC with a clear attacker capability and one written description of the underlying primitive. Most students produce three or four during this phase; one is enough to pass.

Originate. Four weeks. Students pick a primitive class they haven't worked on, and find a new instance of it in a framework they haven't touched. The exit bar is a primitive they discovered, written up to a standard they'd be comfortable publishing. About half the cohort produces something we'd actually publish.

Defence is taught throughout, but only after a primitive has been demonstrated. The pattern is: "here's the primitive you just demonstrated. Here are five mitigations teams ship for it. Here's why three of them don't work. Here's how the other two cost the defender."

The cost

This is the most expensive curriculum we've designed. Two specific costs:

It's harder to hire for. Students need a baseline of comfort with code, threat modelling, and self-direction that not every security background provides. We accept about one in seven applicants.

It's harder to assess at the front door. Many candidates have spent years in defensive roles and have excellent intuitions, but they've never written an exploit. The application process includes a small offensive exercise. About 40% of strong candidates struggle with it the first time. Most of those who push through and complete the exercise are exactly the people we want.

The payoff: graduates ship working primitives in their first month at any team that hires them, and they have an unusually clear voice when explaining mitigations to the rest of the organisation.

What we got wrong, twice

We're three cohorts in. Two early mistakes worth naming.

Cohort 1: too much choice in week one. We let students pick any framework. The strongest students did well; the rest spent two weeks deciding. We now constrain the initial selection to three frameworks and let students pick from there.

Cohort 2: not enough writing. We weighted the curriculum toward technical work and underweighted the writing. The PoCs were excellent; the explanations weren't. We've added weekly writing drills, and the difference in the final write-ups is night and day.

Cohort 4 starts in June. Applications close April 30. The current acceptance rate is 14%.


Mira leads curriculum design at Ryvane Academy. She joined from a previous role running offensive training at a frontier lab.

MC

Mira Carter

Curriculum Lead · Ryvane Academy

From the Ryvane red team.