# Arcanum Prompt Injection Taxonomy: a searchable reference for prompt injection attacks

> The Arcanum Prompt Injection Taxonomy is an open, interactive classification of prompt injection and LLM attacks, built for auditors and penetration testers moving into AI red teaming. It organises 172 nodes into four pillars, cross-references the names other frameworks use for the same attack, and ships the whole thing as a single JSON file for programmatic use.

**Arcanum-Sec/arc_pi_taxonomy** — The Arcanum Prompt Injection Taxonomy

- Repository: https://github.com/Arcanum-Sec/arc_pi_taxonomy
- Website: https://arcanum-sec.github.io/arc_pi_taxonomy
- Stars: 788 · Forks: 135
- Language: Unknown
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/arcanum-sec-arc-pi-taxonomy

## What the four pillars ask

The taxonomy describes itself as an open, interactive classification of prompt injection and LLM attacks, built for cybersecurity auditors and penetration testers moving into AI red teaming.

The organisation is four pillars, 172 nodes in total, and each pillar answers a different question about the same attack.

| Pillar | Code | What it answers | Count |
|---|---|---|---|
| Intents | `PIT-I-NN` | What is the attacker trying to achieve? | 27 |
| Techniques | `PIT-T-NN` | What method manipulates the model? | 70 |
| Evasions | `PIT-E-NN` | How is it obfuscated past filters? | 63 |
| Inputs | `PIT-N-NN` | Where does the payload enter? | 12 |

Splitting an attack along those four axes is the design decision that makes the taxonomy useful rather than merely long. An attack is not one thing but a combination: a goal, a method, an optional obfuscation and a delivery point. Two attacks that look similar in a blog post can share an intent and differ entirely in technique, and two that look nothing alike can share a technique. Modelling them separately means a filter that blocks one evasion does not accidentally block an unrelated intent, and a test case can be described by its parts rather than by a name.

The counts also carry information. Intents are the smallest set at 27 because the objectives are bounded, while techniques at 70 and evasions at 63 are where the combinatorics live, and inputs at 12 are the narrowest because the entry points are few.

## What each node carries

Every entry in the taxonomy has a citable reference code, in the form PIT-I-01 for the example given, so that a finding in a report can point at a specific node rather than at a description.

Each node also carries the alternate names other frameworks use for the same attack, with the README naming OWASP, MITRE ATLAS, NIST, MLCommons and garak among them. That alias list is the feature that makes the taxonomy interoperable rather than competing. A team whose internal runbook says one thing and whose consultant says another can map both onto the same node, and a coverage claim measured in one framework's vocabulary can be translated.

There is a delivery tag on each entry, one of direct, indirect or either. Direct delivery is the payload in the conversation, indirect is the payload somewhere the model reads, and the either category covers attacks that work both ways.

And there are example prompts, which turn the taxonomy from a list of labels into something you can act on. The README also describes a LOCAL flag for white-box attacks that need the model weights, so a tester knows at a glance that an entry does not apply to a black-box API or chatbot. That is a small piece of metadata that saves the most common kind of wasted test, which is trying an attack that cannot work against the system in front of you.

The number of nodes is published as a badge at 172, so you can see the scale of the classification from the header.

## The JSON file is the part to build on

For anyone who wants to analyse, extend or build tools on the taxonomy, the README points at a single data file. The file at docs/data/taxonomy.json is plain JSON, one object with intents, techniques, evasions and inputs arrays, and each node carries code, title, description, aliases, ideas and examples. The documentation says it parses cleanly in any language and is easy for LLMs to consume directly.

There is also a docs/data/taxonomy.js file with the same data wrapped for the web app to load, and the guidance is to treat taxonomy.json as the source for programmatic use.

That separation is the point. The interactive site is the human interface, and the JSON is the machine interface, and keeping the machine interface as a plain data file rather than a scraping target means a tool you build does not break when the site is redesigned.

The format note matters if you are picking this up from an older reference. Versions through 1.0 shipped the taxonomy as one Markdown file per node, and from 1.6 onward it is maintained as the interactive site plus the single JSON data file, with the old per-node Markdown folders retired. The current release is v1.6.1, and the changelog records that v1.6 was a large expansion and rebuild.

So a tool written against the old layout needs rewriting against taxonomy.json, and the code that enumerated the old folders will find nothing.

## The two deployed copies and the contribution loop

The taxonomy lives as an interactive, searchable web app, and there are two deployed versions, a website at arcanum-sec.com/pitax and a GitHub Pages copy at arcanum-sec.github.io. The README describes them as the main, always-current copies, kept in parity and as the canonical reference.

Keeping two deployments in parity is a maintenance decision with a cost, and the repository structure explains how it is paid. The GitHub repository is the canonical source, community input is welcome through issues or pull requests, and reviewed changes are merged there and then deployed to both the GitHub Pages site and the website.

The merge is therefore the single point of truth, and the two sites are outputs of it rather than independent editions. That matters for an auditor who cites a node: the reference points at the repository, and the two sites are the same content at the same revision.

The licence is Creative Commons Attribution 4.0 International, and the README spells out what that permits and requires. You may use, share and build upon the taxonomy, including commercially, provided you give attribution. The required attribution is stated in full: based on the Arcanum Prompt Injection Taxonomy by Jason Haddix, Arcanum Information Security. The suggested citation is given as a formatted reference with the version, the organisation and the site URL, and the taxonomy is credited as created by Jason Haddix and Arcanum Information Security.

The repository itself is small, with a CHANGELOG.md, a LICENSE.md, a README.md and a docs directory, which is consistent with a data-first project where the content is the point.

## Conclusion

The Arcanum Prompt Injection Taxonomy fits a security team that needs a shared vocabulary for prompt injection attacks before writing its own test cases or reviewing an LLM deployment, and that wants a reference other frameworks can be mapped onto rather than another private list. It does not fit as an automated defence, since a taxonomy describes attacks rather than detecting them, and it is not a substitute for your own threat model. Before adopting it, read the version note about the format change, because releases through 1.0 shipped one Markdown file per node and from 1.6 the data lives in a single JSON file, and keep the required attribution, since the CC BY 4.0 licence permits commercial use only with attribution.

## FAQ

### What is the Arcanum Prompt Injection Taxonomy?

It is an open, interactive classification of prompt injection and LLM attacks, built for cybersecurity auditors and penetration testers moving into AI red teaming. It contains 172 nodes organised into four pillars, and each entry has a citable reference code, the alternate names other frameworks use, a delivery tag and example prompts.

### What are the four pillars of the taxonomy?

Intents, coded PIT-I-NN, asks what the attacker is trying to achieve and has 27 nodes. Techniques, PIT-T-NN, asks what method manipulates the model with 70 nodes. Evasions, PIT-E-NN, asks how it is obfuscated past filters with 63 nodes. Inputs, PIT-N-NN, asks where the payload enters with 12 nodes.

### How do I use the taxonomy data programmatically?

Use the file at docs/data/taxonomy.json, which is plain JSON with intents, techniques, evasions and inputs arrays, where each node carries code, title, description, aliases, ideas and examples. The documentation says it parses cleanly in any language and is easy for LLMs to consume directly, and the JavaScript twin of that file is meant for the web app rather than for programmatic use.

### What changed in version 1.6 of the taxonomy?

Versions through 1.0 shipped the taxonomy as one Markdown file per node, while from 1.6 onward it is maintained as the interactive site plus the single JSON data file, and the old per-node Markdown folders have been retired. The current release is v1.6.1, and the changelog records v1.6 as a large expansion and rebuild.

### Can I use the Arcanum Prompt Injection Taxonomy commercially?

Yes. It is licensed under Creative Commons Attribution 4.0 International, so you may use, share and build upon it, including commercially, provided you give attribution. The required attribution is to state that the work is based on the Arcanum Prompt Injection Taxonomy by Jason Haddix, Arcanum Information Security.

## Sources

- [Arcanum-Sec/arc_pi_taxonomy on GitHub](https://github.com/Arcanum-Sec/arc_pi_taxonomy)
- [Issues](https://github.com/Arcanum-Sec/arc_pi_taxonomy/issues)
- [Project website](https://arcanum-sec.github.io/arc_pi_taxonomy)
- [README](https://github.com/Arcanum-Sec/arc_pi_taxonomy/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/arcanum-sec-arc-pi-taxonomy