Methodology

The AI Defense Matrix

The AI Defense Matrix is a grid of eight asset classes (AI-Workload Platforms, AI Orchestration Tools, AI-Generated Code, AI Gateways and Routers, AI Model, Training Data, Runtime AI Data, and AI Agent Identities) by the six NIST CSF functions (Govern, Identify, Protect, Detect, Respond, Recover).

The catalog places each product on the cells where it provides a defensive capability, and marks how central each asset is to the product:

• Primary: A central area this product covers.
• Secondary: A supporting area the product also covers.
• Adjacent: A related area the product touches.

Each function marks a different kind of control. Govern is the narrowest. It marks policy, standards, an inventory or registry of record, provenance, or compliance evidence for an AI asset, rather than the use of AI security in general. A product that only enforces access, discovers assets, or monitors behavior maps to Protect, Identify, or Detect instead.

The AI Defense Matrix is by Lenny Zeltser and Sounil Yu. The catalog classifies and filters products by these asset classes and CSF functions. See the coverage matrix for how many products cover each cell.

Inclusion in the Catalog

The catalog lists products built to defend AI, each mapped to at least one cell of the AI Defense Matrix. Each catalog entry covers one product line, identified by its name.

The catalog excludes vendors, standards, and tools that apply AI only to other security work. A scanner that secures ordinary code is out of scope, while one that targets AI-generated code, models, or agents is in scope. Governance and data products are in scope when they protect, detect, or govern an AI asset. A tool that only measures bias or fairness, with no such defensive function, does not map to a matrix cell and is out of scope.

A capability with its own documentation and configurable behavior counts as a separate product. A plain setting or toggle inside another product is not a separate product, so it stays within that product's entry.

Open-source projects that defend AI are eligible on the same terms as commercial products. A project qualifies when its repository is actively maintained and shows real adoption. When a project is archived or goes idle, the entry typically stays in the catalog with an updated status.

A product qualifies once it is generally available or in public preview. There must also be enough public, dated evidence to source its core fields. Those fields are a description, a deployment model, a status, and at least one matrix cell. Inclusion depends on available evidence rather than on a product's maturity or quality. When a product is acquired or merged, the entry typically stays in the catalog, with the change recorded in the status and history.

To propose a product or request a removal, open an issue in the data repository.

Data Accuracy

The catalog draws each detail from public sources and dates it. AI tooling gathers and analyzes those details, and some errors likely remain despite our efforts to limit them. It is provided "as is," with no warranty that an entry is complete, current, or correct. Products change, vendors update their claims, and sources can be wrong.

Treat the catalog as a starting point and verify anything you plan to act on. We invite the community to flag inaccuracies so we can correct them. To suggest a correction, see CONTRIBUTING and GOVERNANCE.

Framework Relevance

Each product page lists the security frameworks potentially relevant to it, derived from the asset classes it defends on the matrix. The mapping comes from the AI Defense Matrix companion crossmap, which records, per asset class, the controls or techniques that nine security frameworks bring to bear.

This is asset-level inheritance, an editorial inference rather than a vendor claim. It does not assert that a product implements these controls or is certified against any framework. It shows which frameworks speak to the parts of the AI estate the product defends.

Evidence Tiers for Sources

The catalog ties every detail in a product entry to a dated source, ranked by trust:

Vendor

First-party vendor pages and docs. Fine for descriptive details; weaker for comparative or efficacy claims.

Regulatory

Filings and government or standards-body records. High trust for status and compliance details.

Press

Reputable trade and business press. Used for acquisitions and events vendors confirm.

Research

Independent analyst, academic, or testing sources.

Other

Everything else, used sparingly and labeled as such.

Field Origin

Some field values show an Agent tag next to their source. It means an automated check verified the value against its cited page, rather than a maintainer. When a maintainer accepts a correction through a pull request, the value shows no tag.

Compliance Attestations

An entry can list the compliance attestations a vendor publishes, such as SOC 2, ISO 27001, or FedRAMP. Each cites a dated source, such as the vendor trust center. These are published at the company level. One attestation usually covers a company platform rather than a single named product, and the same attestation may appear on several catalog entries from the same company.

The underlying report, such as a SOC 2, is often confidential, so the catalog records that the certification exists without stating which product the report covers.