AI Security Engineering Study Plan

This is a 24-week plan, two weeks per stage at roughly 8 to 10 hours a week, that takes you from threat modeling to AI incident response. Every stage ends with a lab and a deliverable you can publish. Build every lab against one RAG and agent app you own, so the work compounds into a single portfolio instead of twelve toy projects.

Stage 1: Threat modeling and foundations (Weeks 1–2)

Goal: draw an LLM app’s trust boundaries and name the attack class at each one.

Week 1: learn

• Read all ten entries of the OWASP LLM Top 10, plus the appendix that maps them onto an application diagram.
• Skim the MITRE ATLAS matrix and read three case studies end to end.
• Refresh STRIDE and trust boundaries if it has been a while.

Week 2: practice

• Pick a RAG chatbot (your own is best) and draw its data-flow diagram with every trust boundary marked.
• List every place untrusted text enters: user input, retrieved documents, tool output, web pages, file uploads, memory, and logs fed back to the model.
• Run STRIDE per boundary, tag each threat with an OWASP LLM ID and an ATLAS technique, and rank by impact.

Resources, best first

1. OWASP Top 10 for LLM Applications 2025: the shared vocabulary for every later stage. Free.
2. MITRE ATLAS: ATT&CK-style tactics, techniques and real case studies for AI systems. Free.
3. Threat Modeling LLM Applications (AI Village): an early but still useful STRIDE pass over three trust boundaries (users to LLM, LLM to services, LLM to data stores). Free.
4. Threat Modeling Generative AI Applications on AWS: how each STRIDE category reads for RAG, agents and tool use. Free.
5. Microsoft AI Red Team docs: developer threat-modeling guidance, an ML failure taxonomy and a bug bar for triage. Free.

Lab and deliverable: a threat model for your RAG chatbot, with a diagram and one threat table per trust boundary. Keep it in the repo’s docs folder, because later stages update it. Optional: compare your list against STRIDE GPT, but write your own list first.

Stage 2: Prompt injection and jailbreaks (Weeks 3–4)

Goal: tell prompt injection from jailbreaking, and show why filters alone do not stop indirect injection.

Week 3: learn

• Direct versus indirect injection: read Greshake et al. for the original demonstrations against real LLM-integrated apps.
• Willison’s lethal trifecta: private data, untrusted content and a way to communicate externally.
• Instruction hierarchy and multi-turn attacks, where earlier turns prime later ones.
• Play Gandalf through every level and note which defense each level uses (prompt rule, input guard, output guard).

Week 4: practice

• Build the lab below, record a baseline attack success rate (ASR) over about 20 payload variants, patch, then re-measure.

Resources, best first

1. Gandalf with Who is Gandalf: a free game, and the post explains what each level’s system prompt and guard does.
2. The lethal trifecta for AI agents (Simon Willison): short, and the most useful single mental model for agent risk. Free.
3. Not what you’ve signed up for (Greshake et al.): the paper that introduced indirect prompt injection. Free.
4. OWASP LLM Prompt Injection Prevention Cheat Sheet: attack patterns and layered defenses, including the point that guardrail models can themselves be injected. Free.
5. Microsoft AI Red Teaming 101: modular videos on prompt injection and multi-turn attacks. Free.
6. Insights from the world’s largest red team (Zilliz): what tens of millions of Gandalf prompts showed about LLM judges versus text classifiers. Free.
7. Hack The Box AI Red Teamer path: built with Google, with a dedicated Prompt Injection Attacks module. The platform is paid, so check current pricing.

Optional: Learn Prompting’s prompt hacking guide.

Lab: build a small agent that summarizes web pages and has two tools, one that reads a fake notes file and one that sends to a logged stub outbox. Host a poisoned page on localhost that tries to make it read the notes and send them out, and record how often that works across your variants. Then patch in layers: label fetched text as data, flag instruction-like content, drop the outbox tool from any session that reads untrusted pages, and add an egress allowlist. Re-measure after each layer.

Deliverable: a before/after ASR table and a short write-up of which layer did the work. Expect prompt-level patches to be the weakest and the architectural change to be the strongest.

Stage 3: Insecure output handling (Weeks 5–6)

Goal: treat model output as untrusted input to every downstream interpreter.

Week 5: learn

• Map the sinks that model output can reach: browser (XSS), SQL (SQLi), HTTP clients (SSRF), shells and eval (command injection), file paths and templates.
• Read OWASP’s entries on improper output handling and excessive agency, and note the overlap with classic web vulnerabilities.
• Work through the PortSwigger Web LLM attacks labs, which run against a live model, so you may need to rephrase prompts.

Week 6: practice

• Build and exploit the vulnerable app below, then fix it and prove the fix with the same attacks.

Resources, best first

1. PortSwigger Web Security Academy: all labs: the Web LLM attacks track is free and structured Apprentice to Expert. Start with Exploiting insecure output handling in LLMs, where an injected review makes the model emit an XSS payload.
2. OWASP Top 10 for LLM Applications 2025: re-read the improper output handling and excessive agency entries with the labs in mind. Free.
3. OWASP LLM Prompt Injection Prevention Cheat Sheet: covers HTML and Markdown injection in rendered output and least-privilege guidance. Free.
4. Hack The Box AI Red Teamer path: the LLM Output Attacks module is the paid, deeper follow-up.

Lab: in a throwaway container with no network and fake data, build a small assistant that turns a user’s request into a shell command and runs it. Exploit it with a prompt that smuggles a second command. Then fix it in layers: stop using a shell at all and call fixed binaries with argument arrays, validate the model’s output against a strict schema and an allowlist of operations, validate each argument, and run the process with no network and a read-only filesystem. If you write the app in Go, the argument-array form of exec.Command is the natural fix.

Deliverable: the vulnerable and fixed versions side by side in the repo, with a test file that replays the exploit prompts and expects them to fail.

Stage 4: RAG and vector DB security (Weeks 7–8)

Goal: treat document ingestion and retrieval as security boundaries.

Week 7: learn

• Corpus poisoning: read the PoisonedRAG paper, which reports roughly 90% attack success with five malicious texts injected into a knowledge base of millions.
• Embedding and vector weaknesses (OWASP LLM08): retrieval hijack, metadata leakage, and cross-tenant access when tenant checks live only in the app layer.
• ACL-aware retrieval: filter by permission inside the database query, never after retrieval.

Week 8: practice

• Build the two-tenant lab below, break it, fix it, and write up the fix.

Resources, best first

1. PoisonedRAG (USENIX Security 2025) with the paper and code: the key reference, and the code lets you reproduce the attack on a small corpus. Free.
2. OWASP Top 10 for LLM Applications 2025: the Vector and Embedding Weaknesses entry is new in 2025. Free.
3. Not what you’ve signed up for: the indirect-injection paper, since a poisoned document is the same attack delivered through retrieval. Free.
4. Hack The Box AI Red Teamer path: the AI Data Attacks module gives guided practice. Paid.

Lab: stand up a RAG app with two tenants sharing one vector index, where the app filters by tenant after retrieval. Upload a document as tenant A that is written to be retrieved for tenant B’s queries and carries instructions, and show that tenant B’s answers change or that tenant A’s data reaches tenant B. Then fix it: enforce tenant and ACL filters in the vector query (Postgres row-level security works well if you use pgvector), scan and quarantine documents at ingest, record provenance for every chunk, and show source citations to the user.

Deliverable: a reproducible leak demo, the fixed pipeline, and a one-page note on what an ingestion-time control can and cannot catch. Retrieval-time filtering is the control that holds up; document scanning is only a speed bump.

Stage 5: Agent and tool security (Weeks 9–10)

Goal: design agents so that a successful injection cannot do much damage.

Week 9: learn

• Least privilege, confused-deputy attacks, scoped and short-lived credentials, and sandboxing.
• The six design patterns for agents that resist prompt injection, including the dual-LLM and plan-then-execute ideas.
• The OWASP Agentic Top 10, which covers tool use, identity, memory, inter-agent trust and rogue agents.
• The lethal trifecta again, now as a design rule: do not let one session hold all three properties.

Week 10: practice

• Build the permission layer below and test it with the Stage 2 attacks.

Resources, best first

1. Design Patterns for Securing LLM Agents against Prompt Injections, with Simon Willison’s walkthrough: the best practical paper on the topic, written by authors from academia and industry. Free.
2. OWASP Top 10 for Agentic Applications 2026: the risk taxonomy for agents, released December 2025. Free.
3. You cannot filter your way out of prompt injection (Hackernoon): a readable tour of the trifecta, a Rule of Two, the dual-LLM pattern and DeepMind’s CaMeL. Free.
4. Testing the lethal trifecta with promptfoo: shows how to turn the trifecta into an automated test. Free.
5. Hack The Box AI Red Teamer path: the Attacking AI (Application and System) module. Paid.

Lab: give an agent a shell tool and an email tool, both pointed at fake data inside a sandbox. Build a permission layer between the model and the tools. It should hold a per-tool capability list, mark data that came from untrusted sources, and deny any chain such as read-secret then send-external once tainted data is in context. High-risk actions need a human approval step, credentials are scoped per task, and every decision is logged.

Deliverable: the permission layer, a table of the dangerous chains it blocks and the ones it still allows, and a note on which design pattern from the paper each control corresponds to.

Stage 6: MCP security (Weeks 11–12)

Goal: understand why tool descriptions are prompt input, and build detection for tool poisoning, rug pulls and shadowing.

Week 11: learn

• The three core attack classes: tool poisoning (hidden instructions in a description or schema), rug pulls (a server changes its tools after you approved it) and cross-server shadowing.
• Authorization for remote MCP: OAuth 2.1, protected-resource metadata, per-client consent and the confused-deputy risk in proxy servers.
• Controls that matter in production: pinned server identity, curated tool lists, brokered credentials, per-call audit logs and network isolation.

Week 12: practice

• Work through a vulnerable MCP lab, then build your own scanner and run it against it.

Resources, best first

1. MCP Security Best Practices (official docs) and the authorization specification: the primary sources, including the confused-deputy and consent-cookie discussion. Free.
2. Invariant Labs: tool poisoning attacks: the original disclosure that named tool poisoning and rug pulls. Free.
3. MCP Security: Poisoning the Tools Your AI Trusts (Kayssel): a practical tour that points to the Damn Vulnerable MCP Server challenges and Appsecco’s vulnerable MCP servers lab. Free.
4. mcp-scan: the most widely used open-source scanner; read how it hashes tool descriptions to pin them. Invariant Labs was acquired by Snyk in 2025, and it now underpins Snyk’s Agent Scan product.
5. CSA: MCP Tool Poisoning and Rug Pull Attacks: a whitepaper that adds tool squatting and server-package supply chain risks. Free.
6. Speakeasy: MCP security best practices: a production checklist of six controls that references a May 2026 NSA advisory on MCP. Free.
7. A Remote MCP Server Can Rug Pull You (Zuplo): short and concrete on why one-time approval is not enough. Free.

Lab: start with the Damn Vulnerable MCP Server challenges to see each attack class work. Then build a minimal test-fixture server inside the sandbox, with fake data and a local logging endpoint standing in for any exfiltration, that poisons a description, changes it after first approval and collides with a legitimate tool name. Finally write a scanner (Go or Python) that connects, pulls the tool list, pins a hash of every description, flags hidden-instruction patterns and invisible Unicode, detects name collisions across servers, and alerts on list-changed notifications.

Deliverable: the scanner, its test fixtures, and a table of which attack each check catches and which it misses. Add a recommendation on isolating untrusted servers in network-restricted containers, because scanning alone will not catch everything.

Stage 7: Data leakage and privacy (Weeks 13–14)

Goal: measure how much a model memorizes and what a deployed app leaks, then reduce it.

Week 13: learn

• Training data extraction: read the 2021 GPT-2 paper, which showed that individual training examples can be recovered from query access and that larger models are more vulnerable.
• The 2023 follow-up on production models, which reported a divergence attack on an aligned chatbot that emitted training data far more often than normal prompting.
• Membership inference, PII exposure through prompts, logs and RAG context, and data loss prevention (DLP) on inputs and outputs.

Week 14: practice

• Fine-tune a small open model on a dataset with planted canary strings, measure how often they are extracted, and test mitigations.

Resources, best first

1. Extracting Training Data from Large Language Models (Carlini et al.): the foundational paper, with the USENIX Security 2021 page. Free.
2. Scalable Extraction of Training Data from (Production) Language Models: shows extraction from open, semi-open and closed models. Free.
3. NIST AI 100–2e2025: the privacy-attack section gives standard terminology for extraction and inference attacks. Free.
4. OWASP Top 10 for LLM Applications 2025: the sensitive information disclosure entry for application-level leakage. Free.
5. Hack The Box AI Red Teamer path: the AI Privacy module for guided practice. Paid.

Lab: fine-tune a small open model on a public dataset into which you have inserted random canary strings, with a few duplicated more often than others. Prompt it with canary prefixes, count exact and near-exact completions, and chart leakage rate against epochs and duplication count. Then try mitigations: deduplicating the data, fewer epochs, an output filter that detects PII patterns, and a limit on how much context the model repeats.

Get Vicky’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Deliverable: a leakage-rate table or chart, the mitigation results, and a short list of data you should never put in a fine-tuning set.

Stage 8: Model supply chain (Weeks 15–16)

Goal: never load an untrusted model file in a way that can run code, and be able to prove where your models came from.

Week 15: learn

• Why Python’s pickle-based model formats can execute code on load, and how safetensors removes that surface.
• Where scanners help and where they fail: published bypasses of picklescan have been tracked as CVEs, so a clean scan is not proof of safety.
• Model signing with OpenSSF Model Signing and Sigstore, AI bills of materials (AI-BOM), and typosquatting on model hubs.

Week 16: practice

• Build a pipeline that admits models only in safe formats, with a verified signature and a sandboxed load.

Resources, best first

1. Malicious Models: The Pickle in Your ML Pipeline (8ksec): builds a tiny malicious model, shows picklescan, fickling and ModelScan flagging it, and ends with defenses. Free.
2. CSA research note: malicious AI model and skill repositories: in-the-wild campaigns on Hugging Face and the case for signing. Free.
3. OpenSSF Model Signing (OMS) specification intro and the Sigstore model-signing 1.0 announcement: how to sign and verify models with pip install model-signing. Free.
4. ModelScan (Protect AI) and picklescan: the two scanners to wire into CI. Free.
5. Securing LLM dependencies against serialisation attacks (Cloudsmith): shows scanning plus policy rules that block risky models at the registry. Free.
6. The Art of Hide and Seek and PickleBall: research on scanner evasion and safer loading, for when you want to know why scanning alone is not enough. Free.

Lab: in a throwaway container, follow the 8ksec write-up using a harmless marker-file payload, so you can see code run on load and see the scanners react. Then build the admission pipeline: allow only safetensors by default, run ModelScan and picklescan on anything else, verify a model-signing signature against an allowlist of identities, load in a sandbox with no network and a read-only filesystem, and use PyTorch’s weights-only loading where pickle cannot be avoided. Record an AI-BOM entry (source, hash, signer, license) for every model that passes.

Deliverable: a CI job or admission script that refuses the malicious file, with a log showing the reason, plus a short note on what the pipeline would still miss (for example a model that is validly signed but backdoored).

Stage 9: Adversarial ML (Weeks 17–18)

Goal: understand classic attacks on model behavior (evasion, poisoning, backdoors, extraction) well enough to test and defend a model.

Week 17: learn

• Use the NIST taxonomy to organize what you read: attacker goals (availability, integrity, privacy), capabilities and knowledge, and the lifecycle stage attacked.
• Evasion with small input perturbations, data poisoning and backdoors that trigger on a chosen pattern, and model extraction through repeated queries.
• Defenses and their limits: adversarial training, input preprocessing, data sanitization and poisoning detection. Expect none of them to be complete.

Week 18: practice

• Run the backdoor lab below end to end, from poisoning to detection.

Resources, best first

1. NIST AI 100–2e2025: Adversarial Machine Learning taxonomy: the standard vocabulary for predictive and generative AI attacks and mitigations, updated annually. Free.
2. Adversarial Robustness Toolbox (ART) with its documentation: a Linux Foundation AI & Data project covering evasion, poisoning, extraction and inference for red and blue teams across the main ML frameworks. Free.
3. Hack The Box AI Red Teamer path: its AI Evasion modules (foundations, first-order attacks, sparsity attacks) are the most structured hands-on course I found for this stage. Paid.
4. MITRE ATLAS: map each attack you run to a technique and read the matching case studies. Free.
5. Extracting Training Data from Large Language Models: ties this stage back to Stage 7. Free.

Lab: train a small classifier (MNIST or CIFAR-10 is enough). First craft evasion examples against it with ART and measure the accuracy drop. Then retrain with about 1% of the training set poisoned to add a trigger-based backdoor, and confirm that clean accuracy stays high while the trigger works. Finally try detecting it with ART’s poisoning-detection defenses such as activation-based methods, and measure detection rate and false positives.

Deliverable: a notebook with attack success rate, clean accuracy and detection results, plus a half-page note on why a backdoored model that passes ordinary accuracy tests is a supply chain problem and links back to Stage 8.

Stage 10: Guardrails and runtime enforcement (Weeks 19–20)

Goal: put enforcement outside the model, and know what classifiers can and cannot do.

Week 19: learn

• The three layers: input and output classifiers, policy engines and deterministic checks, and human-in-the-loop for high-risk actions.
• Why classifiers are probabilistic, add latency, and can themselves be attacked, so they sit inside a defense-in-depth design.
• What each tool is for: NeMo Guardrails orchestrates conversation flow and rails, Llama Guard classifies safety, LLM Guard scans prompts and outputs, and Guardrails AI validates structured output.

Week 20: practice

• Build the gateway below, then replay your Stage 2 to 6 attacks through it.

Resources, best first

1. Production LLM Guardrails: NeMo, Guardrails AI, Llama Guard compared (PremAI): working examples and a tiered view of cost and latency. Free.
2. Guardrails AI vs NeMo Guardrails vs Llama Guard in 2026 (CODERCOPS): clears up the common confusion that these three compete. Free.
3. NeMo Guardrails vs LLM Guard: a short comparison of dialogue rails versus scanner-style middleware; teams often run both. Free.
4. OWASP LLM Prompt Injection Prevention Cheat Sheet: states that guardrail models are themselves susceptible to injection. Free.
5. Insights from the world’s largest red team (Zilliz): evidence that an LLM judge was itself injectable while a text classifier was not. Free.
6. Design Patterns for Securing LLM Agents: the case for constraining what an agent can do with checks that are deterministic. Free.

Lab: write a policy gateway (a reverse proxy in Go is a good fit) that sits between your agent and its tools. It should validate every tool call against a JSON schema, apply allowlists for tools, domains and file paths, rate-limit by session, and enforce deterministic rules such as no outbound request once untrusted content is in context. Route anything high-risk to a human approval queue and write an audit log. Add one classifier (Llama Guard or LLM Guard) as an extra layer, not as the only layer.

Deliverable: the gateway, a table of block rate and false-positive rate on your attack suite and on benign traffic, and a short note on which blocks came from deterministic rules versus the classifier.

Stage 11: Red teaming and evals (Weeks 21–22)

Goal: turn one-off attacks into a repeatable test suite that gates releases.

Week 21: learn

• The three tools and how they differ: garak is a probe-based scanner for a model or endpoint, PyRIT is a framework for building multi-turn and automated attacks, and promptfoo is declarative app-level evals and red teaming that fits CI.
• Metrics: attack success rate per category, regression suites of attacks you already found, and how to avoid overfitting your defenses to your own test set.
• Automation does not replace manual red teaming. It finds hot spots for a person to explore.

Week 22: practice

• Wire the tools into CI against your app, as described below.

Resources, best first

1. Microsoft AI Red Teaming 101: modular episodes, including automating single-turn and multi-turn attacks with PyRIT. Free.
2. garak (NVIDIA) with docs and the project site: described as the nmap of LLMs, with probes for injection, jailbreaks, data leakage and more. Free.
3. PyRIT (Microsoft) with docs: use the microsoft organization’s repository, since the older Azure one is an archived stub. Free.
4. promptfoo CI/CD guide and the GitHub Action: red-team scans on every pull request, with JUnit output and run tags. Free. A third-party report says OpenAI announced its acquisition of promptfoo in March 2026, so check the project’s roadmap before standardizing on it.
5. Hack The Box AI Red Teamer path: the path HTB announced a certification for, which is the closest thing to a credential for this stage. Paid; check the current status of the certification.

Lab: add a GitHub Actions workflow that runs a promptfoo red-team scan against your staging app on every pull request, and a heavier garak or PyRIT run nightly. Add a regression suite containing every attack you found in Stages 2 to 6. Set thresholds so the build fails when overall or per-category ASR rises, or when any previously fixed attack succeeds again.

Deliverable: the workflow file, a sample failing run with the PR comment or report, and a dashboard or table of ASR by category over time.

Stage 12: Detection, incident response and governance (Weeks 23–24)

Goal: detect a compromised agent, respond to it, and map your controls to the frameworks auditors ask about.

Week 23: learn

• What to log for every model and tool call: session, user, inputs, outputs, tool arguments, retrieved chunk IDs, taint flags and approval decisions.
• Detection signals: an agent acting outside its task scope, tool-call sequences that diverge from the user’s stated intent, and retrieved text that reads like commands.
• Governance: the NIST AI RMF (Govern, Map, Measure, Manage) and its Generative AI Profile, ISO/IEC 42001 as a certifiable management system built like ISO 27001, and the EU AI Act as binding law.

Week 24: practice

• Write the playbook, then run a tabletop exercise with two or three colleagues.

Resources, best first

1. NIST AI 600–1: Generative AI Profile: the practical extension of the AI RMF for LLM risks such as confabulation, data privacy and information security. Free.
2. ISO 42001 vs NIST AI RMF vs EU AI Act (CloudEagle, September 2026): a current comparison that also tracks recent timeline changes. Free.
3. EU AI Act vs NIST AI RMF vs ISO 42001 (CASRAI): a side-by-side table, including why an ISO 42001 certificate does not by itself satisfy the Act’s conformity assessment. Free.
4. AI Governance Frameworks: 9 Key Standards for 2026 (Superblocks): sorts the frameworks into guidance, operating standards and law. Free.
5. OWASP Top 10 for Agentic Applications and related resources: includes an industry framework crosswalk published in September 2026. Free.
6. CISA’s first AI incident response tabletop (SecurityWeek) and Alston & Bird’s summary of its scenarios: a model for what to rehearse, including a malicious model slipped into the environment. Free.
7. KI-Agent gehackt: ein Leitfaden für die ersten 24 Stunden (CIO.de): a practitioner’s first-24-hours playbook for a compromised agent. In German.
8. Indirect prompt injection attack page (PolicyLayer): a list of detection signals such as divergence between user intent and the tool-call graph. Free.

Optional credential: the IAPP AIGP exam covers the EU AI Act, NIST AI RMF and ISO 42001, and this mapping shows how.

Date check: sources disagree on the EU AI Act’s high-risk deadline. A September 2026 comparison says it was deferred to December 2027, while another 2026 overview still lists August 2026. Confirm the date on the European Commission’s AI Act pages before you quote it.

Lab: write an incident response playbook for a compromised agent. Cover detection triggers, triage (what the agent could reach: tools, data, credentials), containment (revoke scoped tokens, disable tools, pause ingestion, quarantine the index or memory), eradication (purge poisoned documents, rotate credentials, re-pin MCP tools), recovery, evidence handling, when to bring in legal, and how each incident becomes a new regression test in your Stage 11 suite. Then run a 60 to 90 minute tabletop with injects such as a poisoned document, a rug-pulled MCP server and an unsigned model.

Deliverable: the playbook (two to four pages), tabletop notes listing gaps and actions, and a one-page map from your controls to the NIST AI RMF functions.

Capstone and portfolio

The twelve deliverables are meant to combine into one public repository: a secure reference RAG agent with its own attack suite.

Repo section

Built in

Threat model and architecture diagram

Stage 1

Attack write-ups with before/after results

Stages 2–4

Permission layer and policy gateway

Stages 5 and 10

MCP scanner and test fixtures

Stage 6

Leakage and backdoor notebooks

Stages 7 and 9

Signed-model admission pipeline

Stage 8

CI red-team workflow and regression suite

Stage 11

Incident response playbook and tabletop notes

Stage 12

Publish a README with a table of attacks against the controls that stop them, write one short post per stage, and record a ten-minute demo. A public repo that shows the attack, the fix and the test that proves it is stronger evidence than a certificate. This skill set is in demand, but no roadmap guarantees employment, so treat the portfolio as the thing you are actually building.

Optional credential: the Hack The Box AI Red Teamer path and its certification (check current status) is the most direct hands-on credential I found for the offensive side.

How the resources were picked, and what to double-check

I ranked resources by four criteria: primary sources first (standards bodies, the authors of a tool or paper), hands-on labs over passive reading, recent work where the field moves fast, and free by default with paid items marked. I could not pull aggregated user reviews, so quality here reflects source authority, the depth of the hands-on content, and the popularity of the projects, not star ratings from learners.

The links come from web searches, and I did not open every page. Before you spend money or quote a date, check these:

• Hack The Box pricing and the current status of its AI Red Teamer certification.
• The EU AI Act’s high-risk deadline, which sources disagree on.
• Tool versions and install steps, especially PyRIT, whose import paths have changed.
• Whether promptfoo’s licensing and roadmap changed after its reported acquisition.

Fastest-moving areas to recheck every month or two: the MCP specification (the authorization spec is still marked draft), the OWASP GenAI Security Project lists, MITRE ATLAS releases, and the NIST AI RMF, which a September 2026 source says is under revision. Prompt injection has no known complete fix, which is why this plan leans on architecture (Stages 5 and 10) more than on filters.