AI Red Teaming Guide: a written methodology for testing AI systems

This guide is a document with a table of contents, not a test harness

The repository is small in terms of code and large in terms of structure. The top level holds README.md plus Spanish, Chinese, and French translations of it, a CHANGELOG.md, an assets directory for images and badges, a templates directory, a resources-validation.md file, and a .lycheeignore file.

That .lycheeignore is a small clue about how the project treats itself. Lychee is a link checker, and ignoring certain URLs from it implies the project verifies that its outbound references still resolve. A resources-validation.md file at the root points the same way: this is a document that cites external frameworks and standards, so the maintenance work is keeping those citations honest.

The project description states the aim directly: a guide to adversarial testing and security evaluation of AI systems, helping organizations identify vulnerabilities before attackers exploit them. The README calls itself AI Red Teaming: The Complete Guide.

What follows from all this is that the artefact is prose plus structure. The table of contents runs to more than fifty entries, and it is the main engineering output: a taxonomy, a methodology, checklists, and a triage model, written so that two teams testing different systems speak the same vocabulary.

Framework anchors: NIST, OWASP, MITRE ATLAS, CSA, and a Microsoft taxonomy

The guide positions itself inside existing standards rather than inventing its own vocabulary. The frameworks section lists the NIST AI Risk Management Framework, the OWASP GenAI Red Teaming Guide, the OWASP Top 10 for Agentic Applications (2026), MITRE ATLAS, the CSA Agentic AI Red Teaming guidance, and the Microsoft Agentic Failure-Mode Taxonomy v2.0.

That list tells you something about the intended reader. A practitioner who has to justify an AI security programme to a risk or compliance function needs mappings onto the frameworks those functions already speak. The guide positions itself as the layer between the standards and the working team.

The sub-sections are equally specific. The OWASP Top 10 for agentic applications is dated 2026 in the heading, and the Microsoft taxonomy is pinned at version 2.0, which means the guide is version-aware rather than generic. That matters for a document whose whole purpose is to be cited.

The maintenance question here is external. Those upstream frameworks move, and a guide that maps to a specific version of each is only correct until the next revision. The presence of resources-validation.md and a CHANGELOG.md suggests the author treats that as a maintenance task rather than a one-off writing effort.

Agent-era attack surfaces get their own chapters

The table of contents shows how much of the guide is about the newer generation of systems rather than chat models. There are dedicated sections on MCP and tool-protocol security, computer-use and browser agent attacks, a RAG attack taxonomy, voice, audio and multimodal attacks, fine-tuning and model supply-chain security, AI-on-AI red teaming, AI coding-agent and CI/CD security, agent-to-agent communication with agent identity, and frontier capability with AI-accelerated vulnerability discovery.

The most recent release makes that explicit. Version v1.2.0, dated 2026-10-01, is titled around Q4 2026 topics and names rogue agents, coding agents, A2A, and frontier capability. Version v1.0.0 came on 2026-06-10 and v1.1.0 on 2026-07-30, so the document has gone through three published versions in four months.

Two sections show unusual care about process rather than technique. There is a metrics section that explicitly names anti-metrics, and a case study quality bar, which reads as an attempt to stop the field from accumulating impressive but unauditable anecdotes. Both are signs the author is trying to raise the standard of reporting, which is a different goal from listing more attack techniques.

Also present are AI incident response, secure SDLC integration artifacts, defensive architecture patterns, multilingual and cultural safety playbook, data governance for red teaming, and purple team operations. The breadth is the point: the guide covers the whole lifecycle from attack to remediation to metrics, which is what a programme needs and what a technique list does not.

The 30/60/90 quickstart and the evaluation harness are the operational core

For a team deciding whether to use the guide, two sections matter most, and they sit next to each other in the table of contents.

The first is an implementation quickstart laid out on a 30/60/90 day structure. The second is an evaluation harness described as a reference implementation. Alongside them sits an agentic AI attack trees and controls mapping, and an AI harm severity and triage model.

The operational sequence the guide proposes is visible in the ordering of those headings:

- [Implementation Quickstart (30/60/90)](#implementation-quickstart-306090)
- [Evaluation Harness (Reference Implementation)](#evaluation-harness-reference-implementation)
- [Agentic AI Attack Trees + Controls Mapping](#agentic-ai-attack-trees--controls-mapping)
- [AI Harm Severity and Triage Model](#ai-harm-severity-and-triage-model)

The templates directory at the repository root is the piece you would expect to accompany those headings, since a quickstart needs forms and a triage model needs a template for recording findings.

What the harness section contains cannot be confirmed from the README, which gives only the heading. It is described as a reference implementation rather than a shipped package, and the repository tree contains no source directory for it, so the honest reading is that the harness is written out in the document. Plan to copy it into your own repository rather than to install it.

Where a written guide is the wrong instrument

The main limitation is the one the project is built around. A guide describes how to think about adversarial testing; it does not execute adversarial testing. There is no runner, no attack library, and no CI integration in this repository, so the gap between reading the guide and having tested a model still has to be filled with your own code, your own model access, and your own budget.

The second limitation is coverage drift. The document pins itself to specific upstream frameworks, to a 2026 OWASP top 10, and to a v2.0 Microsoft taxonomy. Every one of those moves. A team working from a copy taken six months ago may be citing a superseded version without noticing, and the guide's own anti-metrics stance on stale references is a warning about its contents too.

The third is commercial framing, and it is visible rather than implied. The README promotes a paid platform, RedTeamKit, at 249 dollars one-time, the tool section has a featured commercial platform entry for AVERSYN by Cogensec, and the project points readers to a network run by the same organisation. The badge reading trusted by practitioners at is followed by a note that logos represent organizations where individual practitioners reference the guide and that inclusion does not imply official endorsement. That note is good practice, and the commercial sections are still there. Read the comparisons with that split in mind.

The fourth is the licence question. The README carries an MIT licence badge and the table of contents ends with a License section, but the licence recorded for the repository is not stated, so check the LICENSE situation before you republish translated or adapted copies.

Multilingual by design, with a changelog and a link checker

The multilingual setup is one of the more thoughtful operational details in the repository. Four README files sit at the top level, in English, Spanish, Chinese, and French, and the README header offers all four with a language bar. For a document intended to be used by practitioners outside English-first organisations, that is the difference between a reference and a bookmark.

The same attention shows in the maintenance tooling. The CHANGELOG.md at the root records what changed, which pairs naturally with a document that ships tagged releases rather than only commits. The .lycheeignore file suggests broken links are an accepted category of defect worth suppressing deliberately rather than accidentally, and resources-validation.md is the place where external references are checked.

On activity, the last push was on 2026-10-11, and the release history is a sequence of dated, named versions rather than a version-free branch. For a document, that is the right pattern: you can pin a team to v1.2.0 and know what you pinned.

The remaining structural sections complete the picture. There is a building your red team section, best practices, common implementation pitfalls, model and system cards for security posture, source hygiene and update governance, regulatory compliance, a glossary, an acknowledgments section, a contact section, and a disclaimer, plus practitioner appendices and multilingual and cultural safety material. The glossary and the disclaimer are what you would want from a document written to be quoted by people who did not write it.

Editorial conclusion

Adopt the AI Red Teaming Guide as a shared reference and a planning checklist if your team is standing up adversarial testing for LLM or agent systems and wants the vocabulary of NIST, OWASP, MITRE ATLAS, and CSA in one document, with translations for Spanish, Chinese, and French readers. Do not adopt it as a testing tool, since the repository ships no harness code beyond a reference implementation section, and be aware that several sections promote a commercial platform, so treat the tool comparisons with that in mind. Verify three things before you build a programme on it: the licence, which the README presents through an MIT badge while the recorded licence field stays unset, whether the referenced frameworks match the versions your auditors expect, and whether the 30/60/90 quickstart matches your own staffing.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. requie/AI-Red-Teaming-Guide on GitHub