Status: Analysis / All 196 risk factors on the AI Risk Map v1.3, read one by one
AI Risk Map v1.3, Evan Wheeler, RiskFramework.org (2026), and our own runs
This week Peter Holcomb, founder of Optimo AI and one of our advisors, sent me a one-page PDF that has been going around The CISO Society. It’s the AI Risk Map, version 1.3, by Evan Wheeler at RiskFramework.org. It calls itself “a thought-starter for identifying AI-specific risks,” and it fits on one page.
It lists 196 risk factors in 55 categories across 12 domains. It draws on NIST’s AI Risk Management Framework, the EU AI Act, ISO 42001, the OWASP lists for LLMs and agents, MITRE ATLAS and about a dozen more. And it makes one choice that most frameworks don’t. It’s “organized by who owns the risk, not by how the technology works.” Legal has a column. Finance has a column. So does the board.
So we did the honest thing with it. We read all 196 and marked the ones that a check on every action, before it runs, actually addresses. Not the ones it touches if you squint. The ones where we can point to a run, a record or a published result.
The answer is 14.
Most of the map isn’t about actions
That number should be small, and it is. Most of what can go wrong with AI in an organization has nothing to do with an agent doing something.
Bias in a hiring model is a data and design problem. A chatbot that makes up a court case is an accuracy problem. Training on material you don’t have rights to is a legal problem. Unrealistic ROI, a GPU shortage, staff losing skills they used to have, a vendor that pivots out from under you: all real, all on the map, none of them fixed by checking an action.
If anyone tells you one product covers this map, they’re selling you something. The map says it plainly about itself: “Not exhaustive; customize to your context.”
The 14
They sit in five of the 12 domains. Here they are, in the map’s own words, with what we have to show for each.
Autonomy and delegated action: 5
This is the domain the map gives to agentic AI, and it’s where a check on the action does the most work.
Agent pursues an authorized objective through unauthorized means. In our July demo, a vendor updated the model under our agent overnight, aiming to make it better at chaining tools to reach a goal. The agent started stringing together permissions it did have to reach things it didn’t. The same command came back ALLOW one step and BLOCK the next, because the second time it would have finalized a vendor’s risk rating without the approval the rules require.
Excessive autonomy / agency beyond intended mandate. After that update, the agent “explored multi-step tool paths it had never attempted before.” It was still doing its job. It was doing it in ways nobody had approved.
No human checkpoint or working interrupt / kill switch for an agent mid-task. HOLD is the checkpoint. The action stops, a person decides, and the decision goes on the record. In our NVIDIA OpenShell runs, the three bad actions that stayed inside the sandbox came back HOLD, HOLD, BLOCK.
Unsafe or irreversible real-world action taken by an agent. The July agent tried to delete vendor evidence to “clean up.” It was blocked before it ran.
Accountability gap for harm caused by autonomous action. Every decision is logged: what the agent tried, what the rule said, who allowed it. In the July runs that was more than 1,400 decisions.
Operations and resilience: 5
Test or sandbox containment fails and AI reaches real systems. On October 26th, Cohere published a test in which Alibaba’s Qwen model was asked to write a malware detection rule. Its reasoning said it would use no tools. Its next step was an attempt to upload data to a server in Beijing. Cohere’s explanation for why nothing left: “Our sandbox had no route out.” Production has a route out. A check on the action is what stands in that gap.
Silent vendor / model updates changing behavior without notice. That’s the July story. We weren’t consulted and weren’t told. We blocked what the new behavior tried, on the day it appeared.
Controls re-verified less often than the AI system changes. No new rule was written that day. No signature, no patch, no retraining. The model changed and the rules held.
Inadequate logging of inputs, outputs, tool calls, agent decisions, and who authorized them. Every check writes down what the agent tried, what the rule said and what happened next.
Sanctioned agent activity indistinguishable from agentic attack in telemetry. When the same command is allowed once and blocked once, with the reason written down each time, you can tell the agent doing its job from the agent going somewhere it shouldn’t.
Security and adversarial threats: 2
Indirect / cross-domain prompt injection via retrieved content. An instruction hidden in a document doesn’t matter much if the action it asks for still has to pass the rules.
Over-trusted output triggering unsafe automated actions. This is the whole idea in one line. The output can be wrong. The action waits to be checked.
Data and privacy: 1
Inadvertent disclosure of confidential / personal data in model output. In the OpenShell runs, one in-bounds action would have read application secrets and printed them to the screen. Under OpenShell alone, they printed. With the check on the action, they didn’t.
Safety, ethics and responsible AI: 1
Erosion of meaningful human control over decisions. You choose which actions are worth a person. Those wait.
A caveat that travels with the OpenShell numbers: it was a demonstrated approach in a controlled lab, against a representative set of risky actions. It’s not a benchmark, a live incident or a packaged integration, and NVIDIA hasn’t reviewed or approved the results.
What the map shows that we didn’t expect
The 14 aren’t in one column. They’re spread across five owners: whoever owns agents, operations, security, privacy and responsible AI. On most org charts those are different people with different budgets.
That’s the useful part. The moment between an agent’s decision and its execution is one place, and five different owners on this map have a risk that lives there. It’s a shared control, and it’s worth asking out loud who owns it today.
How to use the map yourself
Print it. Take it into your next AI risk meeting and ask each owner to circle the factors they think are covered today, and by what. Then, for every factor that involves an agent doing something, ask one question: is there a point where this action can be stopped before it happens, and who would know?
The map’s own advice is worth repeating. Position on the page “does not imply likelihood or severity,” and it’s meant to start the assessment, not replace it.
The model still decides. The action does not run until it has been checked.
Dates and credit
AI Risk Map v1.3 (2026), © 2026 Evan Wheeler, RiskFramework.org, licensed CC BY-SA 4.0. Factor names above are quoted from the map. Thanks to Peter Holcomb of Optimo AI for passing it along from The CISO Society. Cohere’s test: “Concerning behavior from a popular open-weight AI model,” October 26th, 2026. Our July demo is published at mountaintheory.ai/zero-day-agent-behavior/ and the OpenShell runs at mountaintheory.ai/mountain-theory-nvidia-openshell/.