RAID-AI ransomware framework for AI systems: its console code holds 76 controls, its docs say 90+

76 controls in the console code, 90+ in the documentation

RAID-AI is a free ransomware readiness assessment for AI systems that Infosecurity Magazine described on 30 October 2026. The framework's own pages say it has "90+ controls": the hub home page, the documentation overview and the documentation's version table all use that figure. The script that runs the console, fetched on 30 October 2026, holds 76 control records: 8 Basic, 13 Advanced, 11 High and 44 AI specific (derived by counting them). The documentation also says "Score 70+" in its overview and gives the AI specific tier as about 45+, so its own tier counts add to about 77 (derived: 8 + 13 + 11 + 45). Nothing read says which count is current.

That gap does not show the framework is wrong or careless in every respect. A later build could hold more controls, and a docs page can trail the code. It matters for a narrower reason: the overall score is a plain average over however many controls there are, scored by the user, so the count and the method decide what the headline number means. What the record does not establish is larger. It does not show that ransomware against AI systems is common (the developer told Infosecurity the field is "slowly seeing" such attacks), that scoring well improves any outcome, that anyone has used the tool in a real assessment, or that anyone independent has reviewed it.

How this was read, between 22:41 and 23:02 GMT on Friday 30 October 2026, with each host's robots file read first. The Infosecurity article, the hub pages, the documentation and its framework pages (the documentation is a script driven single page app, so it was read in a browser tab of its own) and the console's script file were saved as text. The console itself needs an account: this briefing did not sign in, did not create one and did not run the app, so what it says about the console comes from reading its published script. Not read: the news page Infosecurity links for the Novo Nordisk claim, which answered with a 403 refusal, so no attempt was made to get past it. Interest: no price, sponsor or vendor product is tied to RAID-AI on the pages read; the section on who built it covers the licence and the creators' employers.

What Infosecurity reported and what the framework's own pages print

Infosecurity's article is the lead source here, and the framework's own pages are the primary. The table sets what each says against what neither prints. "Not stated" means not found in the pages read in full; it does not mean the information does not exist.

The first row of what is stated matches what Infosecurity says. The differences that matter sit lower down, in the name, the OWASP link, the count and the data handling, and the sections below take them in turn.

Who built it, and whose project it is

Infosecurity says RAID-AI was developed over two years by a co lead of the OWASP AI Bill of Materials (AIBOM) initiative with a second co lead. The framework's own team page and the docs name two creators. They describe the first as a co lead and leader of AI red teaming at OWASP's AI Exchange, and the second as a co lead of OWASP AIBOM and co author at the AI Exchange. So the docs place the AIBOM co lead role with the second creator, while the article attaches it to the developer it quotes. This briefing names neither person.

OWASP's own AI SBOM initiative page, read on 30 October 2026, does not mention RAID-AI, and no page read says RAID-AI is an OWASP project. It is presented as its creators' own work under a custom licence. OWASP keeps other pages that were not found, so this shows only what the pages read say.

Commercial interest, stated plainly. The licence lets the creators control commercial use: the console makes users tick a box agreeing not to use it for commercial consulting without written permission, and the docs tell consultancies and managed security providers to contact the creators through LinkedIn. No price, sponsor or vendor tie was found.

The controls: four tiers, seven AI categories, 76 records

The docs describe four tiers: Basic (8 controls), Advanced (13), High (11) and AI specific. The docs add a second dimension, type, so that Basic, Advanced and High are "core" and the rest are AI specific. This is the structure Infosecurity summarised as general and AI specific controls. The console script confirms the three core counts and holds 44 AI specific records, which the docs split into Runtime 17, Supply chain 6, Data 5, Tools 5, Governance 5, Hardware 5 and Detect 1.

Zoom

Zoom

What the controls say is concrete, and the ransomware focus is clearest in the Basic tier. The first Basic control asks for offline, immutable backups of AI artifacts and covers, in the docs' words, "model artifacts, vector databases, embeddings, and system prompt configurations", with quarterly restore tests. The docs rank BS.01 as the single highest impact control. The AI specific controls then reach beyond ransomware proper into prompt injection detection, SSRF prevention, agent tool scoping and GPU firmware, which is wider than the framework's name suggests.

One structural fact is easy to miss. In the console data, only the 32 core controls carry NIST CSF and CISA CPG fields. The 44 AI specific controls carry MITRE ATLAS and NIST AI 100-2 mappings and no CSF or CPG fields, and the script computes the CSF function percentages from the non AI specific controls only (derived from the code). So the two frameworks Infosecurity names first, CSF 2.0 and CPG 2.0, cover 42 per cent of the controls (32 of 76, derived), and the AI specific half of the framework sits outside them.

Zoom

The documentation says Advanced controls need Basic controls at Level 2 or above, and say that without Level 3 across all 8 Basic controls the Advanced and High controls will not provide meaningful additional protection. The console script read has no such gate, as the next section shows. A second point of drift: control titles differ between the docs and the console for 49 of the 76 controls on an exact string comparison (derived), mostly in small wording, for example the docs say Patch and baseline AI hosts where the console says AI Infrastructure Patch and Baseline Management Responsibilities for BS.03.

The 0 to 5 scale, and a score that is a plain average

Each control is scored by the user from 0 (Not Implemented) to 5 (Optimized), with named levels between: Initial, Developing, Defined (3, "fully implemented and consistently enforced" across all in scope systems), Managed and Optimized. The docs tell users to score current state, with evidence, in a workshop, and say a full assessment of all 90+ controls takes two to four hours with the right people in the room. Infosecurity is right that the tool does not verify anything: the score is whatever the people in the room agree to enter.

Zoom

The overall score in the console script is the sum of all control scores divided by the number of controls. Every control weighs the same, and unscored controls count as 0. The code read has no tier weighting, no gate that holds back Advanced scores until Basic is met, and no field for evidence. The docs raise the same worry in words ("Red flag pattern": if Advanced or High averages exceed Basic, review your scoring) but leave it to the user, not the arithmetic.

The last two rows are the ones to hold on to. The docs call offline, immutable backups the single highest impact control and say that without them ransomware is an unrecoverable event. Yet a score of 4.93 with no offline backups falls in the band the docs call Optimized. This is a property of averaging, not of any one user's honesty. The friendly names do the work here: Defined, Managed and Optimized read like statements about control strength, but they are bands of a mean of self assigned integers.

The documentation and the console also describe the CISA score differently. The docs say it is the percentage of CISA goals where at least one mapped control is scored at Level 3 or higher. The console script's own definition is the average of the mapped controls' scores per goal, then the average across goals. The docs also say the CISA CPG "views Level 3 as the minimum threshold" for a baseline. The CISA pages read print goals, outcomes and recommended actions but no maturity level named Level 3; that attribution was not found. Docs bands also differ from the console: the docs give six overall score bands (0.0 to 0.9 up to 4.5 to 5.0), and the script holds four threshold bands for CISA goal scores (below 2, 2 to 2.99, 3 to 3.99, 4 to 5).

The mappings: five frameworks, and checks against the sources they cite

The framework's selling point is that every control is mapped to named frameworks. This briefing checked what it could against the sources the mappings point to: CISA's Cross-Sector Cybersecurity Performance Goals 2.0, read on 30 October 2026, and MITRE's ATLAS data release 2026.10 (modified 28 October 2026). It did not check the NIST CSF subcategory references one by one (30 distinct identifiers appear in the console data, derived).

What this does and does not show. The console stores the identifiers, not the labels, so the wrong labels sit in the documentation, and a user following the identifier still reaches MITRE's technique. But a reader who trusts the label would take AML.T0049 to be prompt injection, which MITRE assigns to AML.T0051. The mappings are the part of a framework like this that a reader cannot easily check, and six of the identifiers the docs label do not match the source's own names. That is a reason to read the mapping tabs as the authors' judgement, not as a derived result.

What the console does with your data

The hub says "No data leaves your machine", and the docs say the app has no server side component and stores assessment state locally. Infosecurity says users do not need to connect systems or upload documents. All three statements fit the assessment content. They sit beside something the pages do not mention in the same breath: the console asks for a sign in.

In the console script, the first screen offers Sign In or Create Account through an identity provider (a third party, Kinde, at a domain named raidai.kinde.com). The screen says the application can see an email address for verification and no other personal information, and that session data and logs reset on every log out or log in. The docs' version table lists Kinde authentication as part of v1.0. The console also shows a licence screen that must be accepted before the dashboard opens, with a Work in Progress notice saying scores and mappings may be updated.

In the script, the only fetch calls found belong to the identity provider's software kit (sign in, token refresh and revoke calls). Scores are held in the page's memory. The only use of browser storage found was the identity provider's session keys. Scores leave the page only if the user exports a JSON file of control identifiers and scores, or prints a report to PDF from a new window. From that, one inference: a reload before export probably loses unsaved scores, so the "stored locally" wording is better read as saved when exported. This was not tested, because the app was not run. The docs also say PDF, CSV and JSON exports in places, while the export page and the script show JSON and PDF only.

The two incident examples, and the hub's own numbers

Infosecurity gives two examples of ransomware attacks on AI systems. Neither survives as an example of what the article says it is when read against its own page.

Read this way, neither example is a documented case of ransomware encrypting an AI system. The Novo Nordisk notice describes data copied out, not encrypted. The claim about stolen models is the claim of the extortionists, reported by Infosecurity as alleged, and it should stay that way. The hub's headline statistics rest on claims too: it reports 1,811 victims in Q1 2026, up 126 per cent, with the source given as ransomware.live. The page's quarterly series gives 800 for Q1 2025, and 1,811 over 800 is a rise of 126.4 per cent (derived), so the arithmetic holds. But a leak site count is a count of claims, as this site's earlier briefing on Q3 2026 showed (247 confirmed by the victim, 2,380 only claimed). The hub then ties the rise to AI assisted campaigns, which the page does not support, and a count of attacks on organisations is not a count of attacks on AI systems.

Established and not established

What to do, in the order the framework's own priorities suggest

This list uses only what the RAID-AI documentation states as controls, ordered by the docs' own implementation priority for the Basic tier, then the Advanced items that most directly serve ransomware recovery. It is a use of their control text, not an endorsement of the scoring.

Technical details

RAID-AI is an assessment tool, not malware, so the primary prints no indicators of compromise, hashes or attacker commands, and none are invented here. The artifacts it does print are control identifiers, formulas, file names and defender guidance text. Each block below is copied from the saved page or script it names, read on 30 October 2026, unless the caption says derived.

The control identifier scheme as the docs print it. It tells a reader which tier or AI category a control belongs to, and the first example is the offline backup control.

AI.R.[TIER].[NUMBER]

Where TIER is:
  BS  = Basic Controls (Baseline Survival)
  AS  = Advanced Controls (Advanced Survival)
  HS  = High Controls (High/Governance)

AI.R.[CATEGORY].[NUMBER]

Where CATEGORY is (AI-Specific):
  DATA        = Data pipeline and integrity controls
  TOOLS       = Tool invocation and interface security
  RUNTIME     = Inference and execution runtime security
  SUPPLYCHAIN = AI software and model supply chain
  GOV         = AI governance and risk management
  HARDWARE    = GPU and accelerator security
  DETECT      = Detection and logging

Examples:
  AI.R.BS.01       → Basic control #1 (Immutable backups)
  AI.R.AS.07       → Advanced control #7 (Secure CI/CD for AI)
  AI.R.HS.03       → High control #3 (Automated kill-switch)
  AI.R.DATA.01     → AI-Specific, Data category, #1 (Input sanitization)
  AI.R.RUNTIME.12  → AI-Specific, Runtime category, #12 (Injection detection)
  AI.R.GOV.01      → AI-Specific, Governance category, #1 (Threat modeling)

The score formulas the docs print for the NIST CSF function view and for ATT&CK technique coverage. Both count a control as covered only at Level 3 or above in the ATT&CK case, and neither weights controls.

FunctionScore = Average(maturityScores of all controls mapped to that function) / 5 × 100%

Example:
  PR controls: [3, 4, 3, 2, 3, 4, 3, 3]
  Average = 3.125
  PR Score = 3.125 / 5 × 100 = 62.5%

TechniqueCoverage = (Controls scored ≥ 3 for this technique) / (Total controls for this technique) × 100%

Overall ATT&CK Coverage = Average(TechniqueCoverage across all techniques)

The two strings from the console script that define the CISA goal score. A defender comparing the console with the docs will see the difference: the docs describe a percentage of goals met at Level 3, and the script describes averages.

cpgGoalScore: average(maturityScore of all mapped AI controls)
overallCisaScore: average(cpgGoalScore across all CPG goals that have >=1 mapped AI control)

The JSON score file the console exports and imports again. The docs call it the most complete representation of an assessment, and describe loading it again under Settings and Export. The shape below is derived from the script, which writes one entry per control with only an identifier and a score.

File name pattern: raid_ai_scores_<date>.json
Contents (derived): a JSON array with one entry per control, each holding two fields: id and score
Import (derived): entries are matched on id, and a control with no entry keeps its current score

Defender guidance text as the docs print it for the first two Basic controls and for the network rule. A defender can turn these into a detection rule for model and vector store files and a firewall rule for AI hosts.

Daily snapshots to offline, WORM/Object Lock storage. Covers model artifacts, vector databases, embeddings, and system prompt configurations. Quarterly restoration testing required.

Enforce MFA on all admin access. Separate admin/service/workload identities. Segment AI infrastructure (model repos, vector stores) from user networks. Block SMB/RDP from user VLANs to AI hosts.

Monitor AI environments for mass encryption of model/vector files, snapshot deletion, inference error spikes, and anomalous API key usage. Correlate storage, runtime, and access telemetry.

Block SMB (port 445) and RDP (port 3389) from user VLANs to AI infrastructure VLANs

The export file names the docs suggest, which matter when scores are archived for audit.

RAID-AI_OrgName_Q2-2025_scores.json
RAID-AI_OrgName_2025-04-01_Executive-Report.pdf

What to hunt and harden, in plain terms: file activity that overwrites or renames many files in model, checkpoint and vector index directories; deletion of snapshots and backup jobs; sudden rises in inference errors; and unusual use of AI provider API keys. These are the signals the docs name for BS.06; the docs print no rule syntax.

The question the score cannot answer

A free framework that names the right assets, model weights, vector stores, embeddings, prompts and agent credentials, and puts offline backups at the top of its list, has done something useful. The framework's value is the checklist of what to protect and how, and a team can take that without the number. The number is where the risk sits. The console averages 76 self assigned integers and can read 4.93 with no offline backup. The pages disagree on how many controls there are, the mappings carry labels that do not match their sources, the OWASP link is an assertion on the creators' own pages and an unconfirmed claim in the news, and no validation is stated.

So the question for any board shown a RAID-AI score is the one the score cannot answer: on the day the model weights and the vector store are encrypted, which copy do you restore from, who has tested that restore, and what did the last test take?

Key facts