Methodology — AI Defense Matrix Catalog

The AI Defense Matrix

The AI Defense Matrix is a grid of 8 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 6 NIST CSF functions (Govern, Identify, Protect, Detect, Respond, Recover).

Every product is placed on the cells where it provides a defensive capability, and 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, not 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 matrix is by Lenny Zeltser and Sounil Yu. Products are classified and filtered by these asset classes and CSF functions. See the coverage matrix for how many products defend each cell.

A sparse or empty cell reflects the market rather than a gap in the catalog. Few products today offer Respond or Recover capabilities for AI assets, so those columns stay thin, and the heat map shows where the industry has yet to build.

What the Catalog Presents

The catalog records the source, date, and trust tier behind every product detail and matrix-coverage claim. With that provenance, you can assess and validate each one yourself. The strategy frameworks are presented as lenses with neutral definitions; the catalog does not offer scores, rankings, ratings, or recommendations, and nothing here is financial or investment advice. You apply the lenses to the details to reach your own view.

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, doesn't map to a matrix cell and is out of scope. A capability with dedicated documentation and configurable behavior counts as its own product, while a settings flag on another product does not.

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 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 stays in the catalog, with the change recorded in the status and history.

The catalog aims for comprehensive coverage within that scope, not a representative sample. It adds qualifying products as they surface, so a crowded matrix cell is expected. That density is a useful signal of where the market is most active.

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. 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. 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, not 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.

Product Strategy and Positioning

Every product page offers two frameworks for weighing a product's strategy and competitive positioning. Applying them is outside the catalog's scope, so the links below point you to the guidance.

Product Strategy: Lenny Zeltser's Security Product Creation Framework looks at how a vendor builds and sells a product.
Strategy Defensibility: Ben Vierck's rubric, reproduced with permission within Lenny Zeltser's Security Product Strategy framework, helps you judge a product's defensibility against market forces.

Evidence Tiers for Sources

Every detail in a product entry is tied 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

Alongside the source, each value records who set it. A person who verifies a value against its cited page marks it reviewed. A value left at its machine-generated seed stays seeded, and a value an automated refresh has updated becomes auto. Automated enrichment can refresh seeded values. For reviewed values it only proposes changes that a person accepts, so a re-run never overwrites verified details. The downloadable catalog.json records the origin of every field.

Compliance Attestations

Alongside description, deployment, and status, an entry can list the compliance attestations a vendor publishes (for example SOC 2, ISO 27001, or FedRAMP), each tied to a dated source such as a trust center. It is an observable detail a buyer can act on, shown only when the catalog has confirmed a public source; it is not a score or a claim that the product is more or less secure.