Become an AI Security Engineer in 5 Weeks

Theme: Get current on the tools, and find out where everyone actually stands.

Theory: What this cohort is building you into, and how the five weeks run. Environment and tooling check. Recap from Break Into AI Testing — Promptfoo configuration, providers, prompts, assertions and model-graded evaluation — then the four settings that are really attack surfaces: tokens and tokenization, the context window, the system prompt, and temperature.

Hands-on: Two paired Promptfoo red-team exercises. Give an AI a narrow job and break it out of its own rules; then audit a higher-stakes agent holding sensitive data and rank what you find by severity.

End-of-Day Deliverable: A working Promptfoo red-team run against a target of your choice, and your first severity-ranked findings list.

Theme: Understand the system you are about to attack, and the market you are about to enter.

Theory: How we got here — Turing, the AI winters, transformers, GPT, and why prompt injection only acquired a name in 2022. The anatomy of the agentic world: LLM, tool and function calling, MCP, skills, memory, RAG, agent-to-agent protocols, orchestrators, swarms, and recursive self-improvement. Where each one opens a trust boundary — including indirect prompt injection through tool descriptions and shared skill files. Why static, single-turn testing stops working the moment an agent can act.

Hands-on: In pairs, take one agentic scenario — a support agent with MCP tools, a coding-agent swarm, a real-time voice banking agent — and produce three attack surfaces, one concrete test you would run, one production signal you would monitor, and one sentence on why Promptfoo alone will not cover it.

End-of-Day Deliverable: An attack-surface brief for one agentic scenario, plus a shortlist of live AI security roles mapped against your own skill gaps.

Theme: Understand the system on paper, get authorized, then check the paper against reality.

Theory: Why CVSS under-scores agents, and how OWASP AIVSS adds agentic factors (autonomy, tool use, memory, dynamic identity and more), scored in a simple first pass. How to run a client intake: business and technical questions asked as a decision tree, not a 100-question form. The OWASP Top 10 for LLM Applications and the OWASP Agentic Top 10 used as a risk checklist. Rules of Engagement: authorization, scope in and out, testing window, limits, kill switch, escalation contacts and evidence handling.

Hands-on: In pairs, read the intake for a fictional retail-bank support agent that has tools, RAG and session memory. State its purpose and the one thing it must never do, shortlist the OWASP risks that apply, and write attack hypotheses ("because it can X, I'll try Y"). Then run the target locally, connect to its API with Postman or curl, and use Claude Code or Codex to map the codebase (recon and fingerprinting).

End-of-Day Deliverable: A risk shortlist and attack hypotheses, a working authenticated connection to the target, and a declared-vs-observed recon table comparing what the client said with what the system actually does.

Theme: Attack the agent by hand first. You can't direct an attacking agent until you can do the job yourself.

Theory: CVSS and AIVSS side by side: deterministic code versus probabilistic, tool-using agents. How to write up recon findings with enough evidence that an engineer can trace the cause. Mapping every attack to both an LLM and an Agentic OWASP category. When a failure counts: reproduce it from a clean session and across variations before calling it a candidate finding.

Hands-on: In pairs, build a Promptfoo attack suite against the bank agent, with single-turn and multi-turn cases, covering indirect prompt injection through a help-center article, access to another customer's account, card-number disclosure, moving money without a real one-time code, a chained attack that reuses a leaked secret, system-prompt leakage, and off-topic output. Then review what the AI generated for you: fix brittle assertions, and use LLM rubrics where exact-string checks can't cope with non-deterministic output. Finally, set up the production-style target used later in the cohort: a containerized chatbot web app, a cloud-hosted open-source model, and Burp Suite for request interception.

End-of-Day Deliverable: A category-mapped Promptfoo attack suite with expected-vs-actual results and your first candidate findings, plus the production-style target used later in the cohort running on your machine.

Theme: Stop attacking by hand. Run an agent that plans, attacks, judges and learns across runs, then investigate what it finds.

Theory: The six-stage episode loop – Wake, Orient, Plan, Attack, Judge, Reinforce – and the memory that carries hits, misses and lessons from one run to the next, so the agent gets smarter and stops repeating itself. Explore-vs-exploit on attack families (UCB1). Single-turn vs. multi-turn attacks with turn caps. Why you point the attacker's model at a local or open-source one rather than a commercial provider: attacking through a commercial model can get your account banned, and a local or open model also means no rate limits, lower cost, reproducible results, and it works where systems can't reach the internet.

Hands-on: In small groups, run the target agent and the attacker agent in two terminals – first as a fixed script, then wired to a real model (GPT-4o Mini, Mistral, Llama 3.2, run locally or via OpenRouter). Read one full episode, one line per stage, and use Claude Code or Codex to trace the campaign files. Answer: after a family wins, does the planner repeat it or move on, and why?

End-of-Day Deliverable: A running attacker agent producing episodes against the target, a written walkthrough of one episode's six stages, and the attacker model swapped from the fixed script to a live local or open-source model.

Theme: Turn candidates into proven findings and wire them into CI/CD.

Theory: Why a candidate isn't a finding until you can reproduce it, and why every re-run starts from a fresh session so context from an earlier run can't fake a leak. The gate that separates a proven finding from noise – three of three by default, or a percentage threshold – as a judgment call where impact weighs as much as frequency: a card number leaking once in a hundred runs is still critical. Promoting confirmed findings to Promptfoo regression files that run in CI/CD, so a bug that's been fixed stays fixed. Shift-left prevention versus incident response. Building a GitHub portfolio hiring teams can read: a branch per exercise, clear commit messages, and one README with a running changelog.

Hands-on: In small groups, add a custom attack strategy to the agent (opening message, follow-ups, family, OWASP IDs, and the goal the judge must prove). Then run the verify step, re-running each candidate several times from fresh sessions; separate confirmed from rejected, read the gate lines (impact, baseline, mitigation, verdict), and decide which findings become Promptfoo test cases, then report the gated findings back to Promptfoo to close the CI/CD loop.

End-of-Day Deliverable: A gated set of confirmed findings promoted to Promptfoo regression files, plus a custom strategy added to the attacker agent.

Theme: Take the week-3 attacker and scale it up. It gets more stages and the option of a model at every stage. A dashboard lets you and your team run it without editing code.

Theory: The full ten-stage loop: Wake, Orient, Plan, Attack, Judge, Reinforce, then Verify, Score, Promote, Report. When to add or cut a stage, for example a human-approval step when a client requires one. Each stage runs as code by default and can be switched to an LLM. The anatomy of an attack: the objective (what you must prove, such as a leaked card number or another customer's data), the family (the type of attack, such as access control, sensitive data or encoding), the strategy (the specific approach), the orchestrator (how the conversation unfolds, such as crescendo or ladder) and the converter (how the payload is disguised, such as Base64). How the planner chooses its next attack family, explained as a gambler choosing between slot machines: keep using what has worked, or try something new. It decides from tries and wins. One set of findings, two reports: an executive summary for stakeholders and a technical report for developers. Confirmed findings feed a Promptfoo regression view built into the dashboard. Your GitHub as your portfolio: public repos, a visible commit history, and the attacker you customise as a portfolio piece.

Hands-on: Clone the advanced attacker, start the target and the dashboard, and set up the target and the attacker's model from the UI. Run a campaign twice: once in mock mode (scripted, no API key) and once against the live target. Then verify, score and promote the hits. In groups, pick three findings and name each one's objective, family, orchestrator and converter. Read the planner's priority bars and explain why a family rose or fell. Use Claude Code or Codex to walk through the architecture plan and the strategy matrix.

End-of-Day Deliverable: The advanced attacker run end to end against the target from the dashboard. A written breakdown of one episode: objective, family, strategy, orchestrator, converter and verdict.

Theme: If you can't explain a framework, you can't sell it. Make the attacker your own, test what changes when its models change, and turn the results into a report a stakeholder can read.

Theory: Learning an unfamiliar codebase with an AI coding assistant. Start from the architecture and flow, then go down into the detail. Ask for a code review, a glossary and a feature list, and use a second model to put technical answers into plain language. Mock versus live runs, and code versus LLM decision-making: a scripted run scores a hit, but a real model like GPT-4o Mini decodes the Base64 payload, sees the intent and refuses. Choosing a model per stage: small or open-weight models for routine decisions, larger ones for planning. Why companies now send tasks to self-hosted open-weight models or commercial APIs depending on cost. Once you have enough logged runs, a large model's results can train a smaller, cheaper model for one job. Keep one shared technical core and change only the content per target: a set of specialised agents, shaped by the client questionnaire, instead of a new agent for every client.

Hands-on: Show the dashboard and terminal changes you made since Day 7 in peer-led groups. Run Blocks 3 and 4 in mock and live mode, switch stages from code to an LLM, and compare the verdicts. Then gather every finding from the weekend into a stakeholder report and present it. The report has an executive summary, a risk ranking with AIVSS context, and recommendations.

End-of-Day Deliverable: A customised attacker dashboard committed to your GitHub repo. A mock-vs-live comparison of the Block 3–4 runs. A findings report on the target (PDF, slides or HTML), presented to the instructors.

Theme: Point everything you've built at a system you've never seen, and stop doing by hand what a script can do.

Theory: Running an engagement against a second target from scratch – read the intake and Rules of Engagement, map the attack surface, then recon and fingerprint the system: model, temperature, context window, whether it uses RAG or tools, rate limits and how it handles odd input. Traditional pen-test tooling on an AI app: Burp Suite to intercept, repeat and modify requests, and an open-source tool that fingerprints the model behind an app from its answers to eight set questions. The OWASP LLM Top 10 (2025 and the new 2026 edition) and MITRE ATLAS as reference catalogs. Manual first, then automate: a runner that sends a file of attacks and logs responses to a CSV, and an LLM-as-judge that labels each one success or fail with a confidence score and a reason – and why a weak judge mislabels, so you verify with a stronger model and a human pass.

Hands-on: In groups, recon and fingerprint the ticketing chatbot through the UI and Burp Suite, run the LLM-fingerprinting tool, work a file of direct prompt-injection techniques by hand, then build a runner that scores the whole file to a CSV and a second script that judges it. Compare judge models.

End-of-Day Deliverable: A recon and fingerprinting write-up of the target, plus your own attack-runner and judge scripts producing a scored findings file.

Theme: The attacks a user can't see – planted in the data the agent reads – and the start of the real work.

Theory: More injection families against the same target: narrative and role-play framing, and encoding or obfuscation (Base64, spacing, emoji). Indirect prompt injection – hide an instruction inside a support ticket so the agent follows it when it later reads the ticket. RAG poisoning – plant instructions in the knowledge base, re-index, and watch the assistant repeat them. Excessive agency, and testing session memory by reusing a conversation ID and cookie. Combining the runner and judge into one pipeline, and feeding confirmed findings back as regression cases.

Hands-on: In groups, run indirect prompt injection through a planted ticket, poison the knowledge base and re-index, test for memory with a reused cookie, and run narrative and encoding attacks through your scripts. Review every "success" by hand against the real response. Career close: a GitHub portfolio as the thing that gets you found, bug-bounty arenas (Gray Swan) as legal paid practice, and the roles this qualifies you for.

End-of-Day Deliverable: A set of confirmed findings across direct, indirect and RAG-poisoning attacks on the ticketing target, reviewed for false positives and committed to GitHub.