The mapping is the sharpest part of the piece for me: excessive agency to tools and permissions, unbounded consumption to rate limits and circuit breakers, hidden context exposure to what actually gets loaded into the window. Each of those is a distinct engineering surface with a plausible owner, which is different from "harness security" as one undifferentiated blob someone eventually inherits.
So the practical question: of those three, are you seeing any of them get a named owner in production, someone whose job is sign-off on tool permissions or provenance on what enters context, or is it still diffuse by default across AppSec, platform, and ML teams? That seems like the actual tell for whether this Top 10 changes anything operationally versus just describing the problem more precisely.
This changes what I diligence in an AI security vendor pitch. I've stopped asking which models they support and started asking whether they can produce a diff between what an agent was granted and what it actually invoked over the last 30 days. Almost every vendor logs actions taken; almost none log the unused half of the grant. If excessive agency is the fastest-growing risk, the permissions nobody's using yet are the part of the harness nobody's pricing.
"Critical controls must not be delegated to the LLM" is the line I'd hand to an executive. Ask a team who owns an agent and you get a real name maybe half the time. Ask who owns the harness and there's usually no name at all, because it got stitched together from a framework somebody picked and whatever the MCP server does. Excessive Agency jumping from #6 to #3 tracks with that. Would the inventory you're describing cover the harness pieces a team inherited, or only the ones they wrote?
Both, but the inherited pieces are the bigger blind spot. A team that wrote a harness component at least knows its grant surface even if nobody's diffing it. A team that inherited an MCP server or a vendor's tool integration usually can't tell you what it's authorized to do at all, only what it did the last time something broke. So when I test a vendor's inventory claim now, I ask them to run the diff on the piece they didn't build, not the one they did. That's where the no name at all problem you're describing actually shows up.
The mapping is the sharpest part of the piece for me: excessive agency to tools and permissions, unbounded consumption to rate limits and circuit breakers, hidden context exposure to what actually gets loaded into the window. Each of those is a distinct engineering surface with a plausible owner, which is different from "harness security" as one undifferentiated blob someone eventually inherits.
So the practical question: of those three, are you seeing any of them get a named owner in production, someone whose job is sign-off on tool permissions or provenance on what enters context, or is it still diffuse by default across AppSec, platform, and ML teams? That seems like the actual tell for whether this Top 10 changes anything operationally versus just describing the problem more precisely.
This changes what I diligence in an AI security vendor pitch. I've stopped asking which models they support and started asking whether they can produce a diff between what an agent was granted and what it actually invoked over the last 30 days. Almost every vendor logs actions taken; almost none log the unused half of the grant. If excessive agency is the fastest-growing risk, the permissions nobody's using yet are the part of the harness nobody's pricing.
"Critical controls must not be delegated to the LLM" is the line I'd hand to an executive. Ask a team who owns an agent and you get a real name maybe half the time. Ask who owns the harness and there's usually no name at all, because it got stitched together from a framework somebody picked and whatever the MCP server does. Excessive Agency jumping from #6 to #3 tracks with that. Would the inventory you're describing cover the harness pieces a team inherited, or only the ones they wrote?
Both, but the inherited pieces are the bigger blind spot. A team that wrote a harness component at least knows its grant surface even if nobody's diffing it. A team that inherited an MCP server or a vendor's tool integration usually can't tell you what it's authorized to do at all, only what it did the last time something broke. So when I test a vendor's inventory claim now, I ask them to run the diff on the piece they didn't build, not the one they did. That's where the no name at all problem you're describing actually shows up.