Your Risk Register Doesn't Know How Your AI Gets Hacked

The gap is not a gap. It is a blind spot.

Your enterprise risk register has no line for an AI that fails when an attacker twists its instructions. But that is exactly how a growing number of AI systems are being broken. Security teams are writing about it daily. Governance teams are not even tracking it.

What most people think

The common view is that enterprise AI governance frameworks, built around fairness, privacy, and compliance, cover the major technical vulnerabilities that security teams uncover. The logic goes: if we have a policy for bias and a checklist for data protection, we have handled the risks that matter. Regulators seem to agree, because the laws they write focus on those categories. So governance teams spend their budgets on privacy impact assessments and bias audits, and they assume the technical layer is someone else's problem.

What the data shows

Our live incident database, which tracks reported AI failures from public news, shows the governance world is not seeing the same events as the security world. In the last 180 days, the MIT AI Risk Repository subdomain 7.3, Lack of capability or robustness, has zero stories in our database. Zero. Meanwhile, our sister platform ThreatClaw, which tracks the threat side, recorded 25 ai-security articles and 11 critical vulnerabilities with active exploitation in just 60 days. That is not a slow trickle. That is a flood.

The incident database itself tells a similar story. In the last 45 days, governance stories dropped from 236 to 150. Security stories dropped from 55 to 42. But the severity mix is still heavy: 69 critical and 319 major incidents in the last 45 days. The news outlets carrying these stories are mostly security trade press, not governance journals. Help Net Security, JD Supra, Tech Policy Press, Biometric Update, and Yahoo Finance together carry just 9% of the last 45 days of coverage. The rest is scattered, but the pattern is clear: the stories that get attention are about privacy leaks, fraud, and multi-agent risks. The stories that get ignored are about robustness failures, overreliance, and environmental harm.

MITRE ATLAS documents real-world cases of attack techniques. LLM prompt crafting has 22 documented cases. Evading an AI model has 18. AI-enabled product or service abuse has 16. AI agent tool invocation has 15. These are not theoretical. They are happening now. And none of them show up in the standard risk taxonomy that governance teams use.

Why this happens

The reason is structural. Governance teams draft policies around static categories like fairness and privacy because those categories map to traditional compliance frameworks. Regulators write laws about discrimination and data protection because those are the harms they understand. So the risk register has a line for bias and a line for privacy, but no line for an attacker who manipulates a model into leaking data or taking a harmful action.

Attackers, meanwhile, do not care about your taxonomy. They exploit robustness gaps. They craft prompts that bypass safety filters. They invoke tools in ways the model was not designed to handle. These techniques are documented in MITRE ATLAS, but they do not fit into the categories that governance frameworks recognize. So they never enter the risk register.

The result is a decoupling. Technical exploitability is real, measurable, and growing. Enterprise risk registers are static, category-bound, and blind to it. The two worlds do not talk to each other, and the governance world is the one that is supposed to be managing risk.

The best argument against this

One honest objection is that governance frameworks are not meant to be threat models. They are meant to set principles and accountability structures. The technical layer is handled by security teams, who do their own risk assessments and incident response. So the governance gap does not mean the risk is unmanaged. It just means it is managed elsewhere.

That argument has some force. Security teams do exist. But the problem is that the governance framework is what regulators look at, and what boards review. When a breach happens, the post-mortem will ask why the risk register did not flag the vulnerability. If the register has no category for robustness failures, the answer will be that it was not a tracked risk. That is not a defense. That is a confession.

And the decoupling is not just a paper problem. It affects budget. Governance teams allocate resources based on their risk register. If the register does not list robustness, no one funds robustness testing. Meanwhile, the security team is fighting active exploits with whatever they can scrape together. The result is that the most exploitable vulnerabilities get the least attention.

What I think happens next

By July 2027, at least 40% of major enterprise AI security breaches will stem from robustness failures that are categorized as non-existent in current governance frameworks. That is my prediction. It is based on the trajectory we are seeing: the attack techniques are documented, the news is covering them, and the governance frameworks are not adapting. The EU AI Act's high-risk rules do not apply until December 2027, so there is no regulatory push before then to force the change. The Colorado ADMT Act starts January 2027, but it focuses on algorithmic discrimination, not robustness. So the gap will persist.

What would prove me wrong is if, by July 2027, enterprise AI incident disclosures attribute less than 10% of breaches to robustness or capability failures in published post-mortems. If that happens, I will accept that the governance world somehow caught up. I do not think it will.

What to do about it

Start this week. Do not wait for the regulator.

• Map every technical CVE category from your threat intelligence feeds directly into your enterprise AI risk assessment criteria. If a CVE exists for an AI component, it belongs in your risk register. Use the MITRE ATLAS techniques as a checklist. If a technique has documented real-world cases, it is not theoretical.

• Mandate robustness stress-testing alongside fairness audits before any model deployment. Your model may be fair and still be vulnerable to prompt crafting. Test it the way an attacker would. If you do not know how, use the MITRE ATLAS cases as a starting point.

• Create a standing review that compares your risk register against your threat intelligence feeds at least monthly. The ThreatClaw briefings are one source, but any feed will do. The point is to force the two worlds to meet.

• Add a category for robustness failures to your risk taxonomy, even if your framework does not require it. Name it plainly. Give it a severity scale. Assign an owner. If you have no owner, that is your first finding.

• When you report incidents internally, include a line on whether the root cause was a robustness failure. If it was, say so. If you do not know, that is a finding too. The data you collect now is the data that will save you later.

A governance programme that tracks only the categories regulators mention is not managing risk. It is managing paperwork. The attackers have moved on. Your risk register should too. If you want a concrete example of how an AI can fail in a way your register does not capture, read "When Your AI Secretly Memorizes Customer Passwords" on ThreatClaw: https://www.threatclaw.ai/blog/when-your-ai-secretly-memorizes-customer-passwords. It is a real failure mode, and it is not in your taxonomy.

More from our platforms

These sister platforms cover the parts of this problem that sit outside governance.

• Argus (argus.threatclaw.ai) records every trace an AI application produces and scans it for prompt injection, jailbreaks and data leaks, including the attacks hidden inside retrieved documents and tool results rather than in what the user typed. Governance decides what an AI agent is allowed to do. Argus shows what it actually did.
• ThreatClaw (www.threatclaw.ai) tracks the threat side of the same systems: 22 live intelligence feeds, exploitation predicted before it is officially confirmed, threat actor profiles, and detection rules you can deploy straight away. A control is only as good as the threat it is sized against.
• Xodexa (xodexa.com) runs 300 AI agents through structured, multi-round debates on the questions that do not have settled answers, and publishes the verdicts and the predictions that come out of them. Useful when the governance question is genuinely contested and you want the strongest version of the other side.

Related reading:

• When Your AI Secretly Memorizes Customer Passwords on ThreatClaw
• Your AI Needs a Safety Net in Layers on ThreatClaw