A practical, evidence-led learning path for securing systems that use large language models, retrieval, tools, agents, and the Model Context Protocol (MCP).
AI security is not a synonym for jailbreak collecting. A useful practitioner must be able to model a system, locate trust boundaries, test a concrete failure hypothesis, interpret imperfect evidence, design layered controls, and verify that those controls still work after the product changes. This repository teaches that workflow.
The roadmap is independent educational material. It is not an official publication of OWASP, NIST, MITRE, Google, Microsoft, NVIDIA, Promptfoo, ISO, or the MCP project, and it does not certify compliance with any framework.
- application-security and product-security engineers moving into AI systems;
- ML and platform engineers who need security fundamentals around LLM applications;
- red teamers who want reproducible, authorized AI assessments;
- blue teamers building telemetry, detection, containment, and incident-response paths;
- governance and assurance practitioners who need to connect technical evidence to risk decisions.
You should already be comfortable with HTTP, APIs, identity and access control, logs, basic Python or JavaScript, and ordinary secure-development concepts. The first module identifies the prerequisites worth filling before continuing.
This repository is a learning roadmap and field guide. It explains what to learn, in what order, how the pieces connect, and what evidence a learner should produce.
It deliberately does not duplicate ai-cybersecurity-skills, which contains operational instruction packages for AI agents. It is also not a payload dump, a benchmark leaderboard, a compliance checklist sold as proof, or permission to test systems you do not own.
| Module | Outcome |
|---|---|
| Foundations | Distinguish model, application, infrastructure, and governance risk; establish the prerequisites. |
| Threat modeling | Turn an architecture into assets, trust boundaries, abuse paths, controls, and testable hypotheses. |
| LLM and RAG security | Analyze prompt injection, data exposure, output handling, retrieval authorization, provenance, and poisoning. |
| Agent and MCP security | Secure tool use, identity, memory, delegation, approvals, tokens, and MCP authorization boundaries. |
| Secure lifecycle | Integrate governance, design review, supply-chain checks, evaluations, release gates, monitoring, and response. |
| Red and blue teaming | Run authorized, hypothesis-led tests and convert failures into detections, controls, and regression cases. |
| Hands-on labs | Produce a threat model, an injection evaluation, a RAG test, an agent-control review, and a release decision. |
| 12-week roadmap | Follow a realistic sequence with weekly outputs instead of passively consuming material. |
| Role-based paths | Adapt the core to AppSec, ML engineering, red team, blue team, or governance work. |
| Field checklists | Use concise design, test, release, and incident-response prompts without treating them as certification. |
| Glossary | Use core terms consistently. |
| Primary sources | Read the authoritative material behind the roadmap. |
The Turkish edition follows the same spine but adds context, examples, common mistakes, and locally natural explanations. It is not a line-by-line translation.
- Read the foundations and choose a role path.
- Work through the 12-week plan. Do not skip its artifacts: diagrams, test cases, risk decisions, and retrospectives are the actual learning evidence.
- Keep all active testing inside an explicit authorization boundary. Use local or synthetic targets for the labs.
- Record both attack and benign control cases. A system that blocks everything is not secure; it is unavailable.
- Re-run the same cases after each meaningful model, prompt, retriever, tool, policy, or dependency change.
Use four labels in notes and reports:
- Verified: directly supported by code, configuration, trace, log, or an authorized reproduction.
- Supported inference: a reasoned conclusion with the supporting evidence and uncertainty stated.
- Unverified: plausible, but the required access or evidence is missing.
- Not tested: intentionally outside scope or blocked by safety, access, cost, or environment constraints.
A suspicious prompt, a scanner hit, or an OWASP label is not automatically a vulnerability. A defensible finding identifies the affected boundary, preconditions, evidence, impact, confidence, remediation, and retest method.
The labs are defensive and use synthetic data. Before active testing, establish written authorization, target identifiers, allowed techniques, time and cost limits, data-handling rules, stop conditions, and an escalation contact. Do not test third parties, persist, evade oversight, exfiltrate real data, or use production secrets. Stop at the minimum proof needed to demonstrate the risk.
See Red and blue teaming and the authorization template before running any assessment.
The validation suite is dependency-free:
make checkIt checks the document inventory, internal links and anchors, source-domain policy, JSONL fixtures, placeholder hygiene, and key safety statements. External links can be checked separately:
python3 scripts/check_links.py --externalExternal validation includes inline and reference-style Markdown links, citation metadata, and the license URLs. Before the first GitHub publication only, the declared repository and release URLs legitimately return 404. Audit that state explicitly without hiding it:
python3 scripts/check_links.py --external --allow-prepublication-pendingThe prepublication flag converts only exact 404 responses for this project's GitHub repository and semantic-version release URLs into visible External pending results. It does not suppress any other error. Final release verification and CI must use the strict command without this flag.
External checks require network access and can fail transiently because a publisher rate-limits or blocks automated requests. CI therefore treats local-link validation as the required gate and runs strict external validation on a schedule and by manual request.
Read CONTRIBUTING.md. Contributions should improve a concrete learning outcome, cite primary or authoritative sources, preserve the authorization boundary, and avoid unsupported claims.
Apache License 2.0. See LICENSE.