---
title: MIT Asked 272 Experts Who Owns AI Risk. They Picked the One Group That's Never Carried It.
description: MIT's expert panel assigns developers primary responsibility for AI security risk: 5 of 5, full consensus. Thirty years of breaches say developers have never carried security, not because they don't care, but because nothing in their incentives or structure makes them. That gap is where agentic breaches will live.
url: https://ziosec.com/blog/mit-asked-272-experts-who-owns-ai-risk
category: Blog
publishedAt: 2026-06-11
author: Aaron Walls
authorRole: Co-Founder & CEO
tags: ai-agent-security, ciso, ai-risk, governance, agentic-trust
---

MIT's AI Risk Initiative just published a Delphi study worth sitting with. They asked 272 experts to score who should bear responsibility for managing each category of AI risk, across seven actor types: developers, deployers, governance bodies, AI users, infrastructure providers, and general stakeholders. The scale runs from 1 (not at all) to 5 (primary responsibility), with checkmarks marking full expert consensus.

Scan the row for AI security vulnerabilities. General-purpose developers: 5 of 5, primary responsibility, expert consensus. Specialized developers: 5 of 5, consensus again. AI users, the people actually operating these systems? A 2. Minimal.

The experts could not be clearer. Developers own AI security. Full stop, checkmark, consensus achieved.

In theory, that's correct. Developers write the code. They wire the tools. They decide what an agent can touch, what it can call, and what happens when it fails. If responsibility followed proximity to the blast radius, developers would own security outright.

In practice, we've run this experiment for thirty years, and we know exactly how it ends.

## Look at what's missing from the chart

MIT's actor taxonomy has columns for developers, deployers, governance, users, infrastructure providers, and stakeholders. Notice the column that isn't there.

There is no CISO.

The one role our industry actually fires when security fails does not exist in the academic responsibility model. That's not an oversight by the MIT team; their taxonomy reflects how responsibility should be distributed in a rational system. But it accidentally proves the point. We built an entire executive function specifically because the actors who should own security don't, and that function is so divorced from the theoretical model that it doesn't even rate a column.

If the industry genuinely expected developers to shoulder security, the CISO role wouldn't exist in its current form. We invented a dedicated executive whose job is, functionally, to make other people care about security and to absorb the consequences when they don't.

Developers don't get fired for breaches. CISOs do. That's not cynicism, that's the observed failure mode of the entire industry. The accountability and the activity live in two different org boxes. The person closest to the vulnerable code has the least career exposure to it, and the person with the most career exposure has the least direct control over the code.

To be precise about the failure: developers don't lack ability, and most don't even lack interest. They lack incentive and structure. They get measured on velocity, security work is invisible until it isn't, and nothing in the sprint board rewards the feature that didn't get breached. Security gets engineering attention under exactly three conditions: infosec forces the issue, GRC forces the issue, or something detonates. Ransomware is a remarkably effective prioritization framework. Nothing else reliably moves a backlog.

The MIT experts aren't wrong about where responsibility should sit. They're describing a normative ideal. The org chart describes reality. The gap between those two things is where breaches live.

## The second chart makes it worse

MIT also published a butterfly chart comparing the responsibility experts assign to each actor against the vulnerability they attribute to it. Red bars for responsibility, blue bars for exposure.

![MIT actor vulnerability vs. responsibility butterfly chart, with red responsibility bars and blue vulnerability bars across the same risk subdomains](/blog-images/mit-asked-272-experts-who-owns-ai-risk-butterfly.png)

For developers, the red bars dominate. For AI users and general stakeholders, the pattern inverts: long blue bars, short red ones. The people experts hold responsible are not the people who absorb the harm.

So map the full disconnect. Responsibility on paper goes to developers. Harm in reality lands on users and stakeholders. Accountability in practice lands on a role the model doesn't even include. Three different groups, three different fates, and the only one with the power to prevent the incident is the one with the least incentive to.

## Agents make the gap lethal

Now look at row 7.6, multi-agent risks. It's the only row in the entire matrix where general-purpose developers, specialized developers, AND deployers all score a 5 with consensus. The experts effectively declared that everyone building and shipping agentic systems holds primary responsibility simultaneously.

They're right to sound the alarm. With traditional software, the responsibility gap was survivable. Code did what it was written to do. The attack surface was static enough that infosec could come in behind engineering, scan, patch, and audit. Slow, adversarial, inefficient, but workable.

Agentic AI breaks that model completely. An agent isn't a feature that ships and sits still. It's software that makes decisions, chains tools, calls other agents, and changes behavior based on inputs nobody reviewed. The developer who deployed it on Monday cannot tell you what it will do on Friday.

The deployment math is unforgiving: 88% of enterprises will be deploying agents by the end of 2026, while 85% of the agentic attack surface is currently untested. 38% of businesses already have unauthorized agent deployments their security teams haven't sanctioned, and 48% of CISOs now name agentic AI as the top attack vector for 2026.

So we're scaling a class of software that's harder to reason about than anything we've shipped before, handing it to a developer population that has never been incentivized or structured to own security, and the expert consensus answer is "developers should be responsible."

That's not a plan. That's a pre-written incident report.

## Stop assigning responsibility. Start producing evidence.

The fix isn't a better lecture for engineering teams. Thirty years of secure coding training, OWASP top tens, and shift-left evangelism produced the world we currently live in. Hoping that agentic AI is the thing that finally rewires developer incentives is a bet against three decades of evidence.

The fix is to stop making security depend on any individual actor's diligence at all. That means treating agent trust as a continuous evidence problem rather than a responsibility assignment problem:

**Discover** every agent in the environment, including the 38% nobody approved. You can't assign responsibility for software you don't know exists.

**Validate** agent behavior with continuous offensive testing. Not an annual pentest, not a questionnaire asking the developer if they followed best practices. Actual adversarial pressure against the running system, all the time, because the agent that passed in March is not the agent running in June.

**Govern** with policies inferred from what agents actually do, not what their builders intended. Intent doesn't survive contact with production.

**Attest** with portable evidence that the CISO, the GRC team, the customer, and the regulator can all consume. Because when responsibility is contested, evidence is the only thing that settles the argument.

When the trust layer runs independently of developer attention, the MIT responsibility matrix stops being a wish list. The CISO stops being a scapegoat and becomes the operator of a system that doesn't require anyone's good behavior to function. Developers keep shipping at the speed their incentives demand. And the gap between who should care and who actually does stops being the place where breaches happen.

The experts are right that someone has to own this. The lesson of the last thirty years is that "someone" can't be a job title, especially not one that's missing from the chart. It has to be infrastructure.

*Source: [MIT AI Risk Initiative](https://airisk.mit.edu/), Actor Responsibility Matrix and Actor Vulnerability vs Responsibility analysis, Delphi study of 272 experts.*