Why This Roadmap Exists

Most roadmaps for AI security careers get the same three things right and the same five things wrong.

They get right: the job titles, the core skills, and the idea that you should build something in ninety days. Those are real, and they are useful.

They leave out: the threat landscape you are supposedly securing, the governance frameworks that decide whether your findings become action, the community and credential signals that make a stranger trust your work, the actual mechanics of converting a portfolio into interviews, and any plan for what happens on day 91.

This site is the version with those five gaps filled in.

The argument in one line

The market is not short of security engineers who can build an agent. It is short of people who can prove how an agent fails — reproducibly, with logs, mapped to a recognized framework, and explained to someone who controls a budget.

That sentence determines the shape of everything here. It is why the threat landscape comes before the skill tree, why the 90-day plan makes you attack your own work in month two, and why every portfolio project is required to carry a section titled “how this agent fails.”

Why agentic security is a different problem

A model that answers a question has one failure mode: it says something wrong. An agent that acts has four:

• It has capabilities. It calls tools, runs code, sends messages, moves money. A successful influence operation against the model becomes an action in the world.
• It has memory. What it learns in one session persists. A single poisoned input can have a delayed and repeating effect.
• It has an identity. It authenticates to systems, often with broader privileges than any human user and often with no clear owner.
• It trusts its inputs. Retrieved documents, tool outputs, and peer-agent messages all land in the same context window as the operator’s instructions, with no privilege separation between them.

That last point is the structural one. Nearly every attack in the threat catalogue is a variation on instructions and data share a channel — which is also why filtering inputs never fully solves it, and why durable control has to move to the tool, identity, and approval layers.

What “proof” looks like

The word doing the most work above is proof. Concretely, it means four artifacts, and they are the same four every serious portfolio has:

1. A threat model with trust boundaries drawn, not just a box diagram.
2. A trust boundary and approval design that explains which actions require a human and why — with irreversibility and blast radius as the stated criteria.
3. An audit trail sample showing that you can reconstruct what the agent did, with what arguments, on whose authority.
4. A failure analysis that says what you attacked, what worked, what did not, and what you never tested.

The fourth is the one people skip, and it is the one that reads as senior. Volunteering the limits of your own work is the clearest available signal that you understand it.

How to use this site

If you have thirty minutes, read the roadmap overview and the threat landscape introduction. That is enough to know whether this field is for you.

If you have ninety days, follow the plan and run the labs in order. You will finish with two working agents, a red team report against your own systems, an instrumented audit trail, and a risk register.

If you are already working in the field, the sections most likely to be new are evidence automation and the continuous learning loop — the parts about staying useful after the initial ramp.

Everything here is opinionated on purpose. Where the guidance is contestable, it says so.