Attacking & Threat Modeling The Agentic Top Ten: ASI02 - Tool Misuse and Exploitation
Part 2 in a series applying Future Proof AI engineering--threat modeling, secure ops, & design for test--to the OWASP Agentic Top 10 | Edition 41
We’re continuing our coverage of the OWASP Agentic Top Ten with ASI02 - Tool Misuse and Exploitation.
This series on the OWASP Agentic Top Ten is intended to bring together the Top Ten’s practical advice with bleeding edge research and attack methodology from the trenches.
The goal: Equipping teams to build truly Future Proof AI.
The dual focus on attacking & threat modeling is because these are two sides of the same coin. They always have been–but AI is now making that fact unavoidable.
You can find Part 1: ASI01 - Agent Goal Hijack, here.
Future Proof AI is threat modeled, designed for testing, and operationalized securely.
Let’s go.
Image: Hi from a DC basement. Let’s call it a LAN party.
Blink and you’ll miss the lede that’s almost buried in the Agentic Top Ten’s ASI02: Tool Misuse and Exploitation.
That’s because the use of tools (and the effects on resources they can have) is so central to Agentic form, function, and behavior–and also so vulnerable–that there is far more than one way Agentic tool use can go wrong.
“More than one way” here actually implies there are categorically multiple ways that Agentic tool use can fail.
ASI02 represents only one subset of vectors.
And this is the lede, aka the point I don’t want anyone to miss: AI Agents using tools are very likely your greatest liability.
Tool use is so susceptible to attacks that while it has its own category in ASI02, it’s represented across multiple Agentic Top Ten areas:
“If the misuse involves privilege escalation or credential inheritance, it falls under ASI03 (Identity & Privilege Abuse); if the misuse results in arbitrary or injected code execution, it is classified under ASI05 (Unexpected Code Execution).”
Let that sink in.
In addition to the misuse and even possible direct exploitation of Agentic tool access, Agent tool use appears in multiple other vulnerabilities.
Agentic tool use is so perniciously vulnerable that it functionally takes up at least three positions on the Agentic Top Ten.
The Many Ways Agentic Tools Fail
You could argue that there’s always overlap among vulnerabilities in practice, particularly when we’re dealing with the overarching (and underpinning) mathematical security vectors of AI systems. Sure.
But there’s no arguing that things change when you give these vulnerable systems the ability to act in the real world.
ASI02 is about unwanted operations with legitimate tools–in other words, it covers the cases where authorized tool use goes wrong.
If you think about it, this is a broad–but also very specific–category of vulnerability.
What do I mean?
To understand how to apply this lens when looking at threats to Agentic systems, let’s take a moment to revisit the types of tools that Agents access and use.
The word tools here implies the ability to access or alter resources, too–something worth considering.
Because the entire intention behind Agentic deployments is flexible automation, these tools cover an incredibly wide range of applications–and abilities.
The key to remember here is that this vulnerability isn’t about broken authorization–it’s what happens when legitimate access goes awry. And the consequences of such a failure are defined on a per-system basis, around the types of tools and access that the Agents require to do their job.
Or–as is often the case–the tools they’re given, which may exceed the requirements of just doing their Agentic jobs.
It’s devastatingly easy to see how excessive Agentic tool access can be severely compounded by even a small instance of tool misuse or malicious exploitation.
If this reminds you of LLM06:2025 - Excessive Agency from the Top Ten for LLMs, you’re absolutely correct. And the Agentic Top Ten is explicit about this fact:
“This relates to LLM06:2025 (Excessive Agency), which addresses excessive autonomy but focuses on the misuse of legitimate tools.”
I often talk about how Agentic systems inherit the vulnerabilities of LLMs (and the systems that came before them).
This is a prime example of that exact phenomenon.
So when you deploy Agents, you’ve really got multiple potential tooling problems on your hands: The number and scope of tools Agents can access, and the level of authorization they’ll possess.
Each one of these dimensions requires careful consideration at every step of the development process.
You can see how quickly these decisions compound–in both complexity and consequences (depending on the Agentic architecture).
Remember, Agentic security depends heavily on architectural choices–failures can cascade and/or compound differently depending on the shape of the Agentic deployment.
As an Agentic deployment scales, these decisions also increase in number.
An enterprise Agentic deployment may consist of thousands of Agents. How are you deciding which Agents get access to which tools? How are you setting levels of Agentic authorization?
Are these methods consistent and systematized? Are they repeatable?
Are they understood by your team, and implemented?
This is why threat modeling for Agentic deployments before, during, and post-development is absolutely mandatory.
You cannot develop secure, effective Agentic systems without considering how you will handle delegating their tool use at scale.
If your Agentic system is able to act within its authorization using tools, but still create problems you didn’t want or anticipate, you have a Tool Misuse (and/or possibly Exploitation) issue on your hands.
Failure Modes Vs Failure Effects
We’ve covered the failure mode–authorized tool use gone wrong–but what are the failure effects? How would we know something bad has happened? What are we looking for here?
The Top Ten gives several cases demonstrating what can go wrong in its definition of Agentic tool misuse, and the list should give anyone deploying these systems pause.
At least two potential failures of data handling come up here. That’s because the tools Agents use frequently give them the ability to access or even manipulate data.
The natural result of this is the potential–depending on use case–for data to be exfiltrated, or deleted altogether.
These failures are in addition to problems that can arise around resource usage, as the Top Ten lays out:
“This entry covers cases where the agent operates within its authorized privileges but applies a legitimate tool in an unsafe or unintended way - for example deleting valuable data, over-invoking costly APIs, or exfiltrating information.”
These and other failures can arise with hijacked workflows & manipulation of tool outputs.
The list of contributing factors–prompt injection, misalignment, unsafe delegation,
ambiguous instruction–make Agentic tool use an incredibly attractive vector for attackers.
And this matters even beyond the potential blast radius of any attack on tool use.
Will such an attack be devastatingly effective? Most likely. And will it get to–and exploit–the very heart of what makes a system Agentic in the first place? Absolutely.
But even more than that, Agentic tool use just provides so many methods and entry points that it’s one of the most, if not arguably the most, potentially viable path for attackers.
You could argue that memory components make an incredibly enticing vector, too.
But to be fair, these interplay often with Agentic tool usage–which means they serve to amplify ASI02’s vulnerabilities.
Remember, ASI02 is about when authorized tool use goes bad–it’s clear in its specificity regarding whether the tool access is legitimate. For ASI02, it is.
What’s unwanted is how the tools are used–and the effects this misuse causes.
If you test these systems, take note. And if you defend them, you’re going to want to take several notes.
ASI02 isn’t a single vulnerability so much as an attack paradigm.
Stay frosty.
The Threat Model
Agentic tool use is so vulnerable that it functionally takes up three slots on the Agentic Top Ten.
As Agentic deployments scale, so do the number, complexity, and consequences of tool delegation decisions.
The intersection of vital (and often shared) memory components with Agentic tool usage amplifies the vectors.
Resources To Go Deeper
Hou, Xinyi, Yanjie Zhao, Shenao Wang and Haoyu Wang. “Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions.” ArXiv abs/2503.23278 (2025): n. Pag.
Krishnan, Naveen. “Advancing Multi-Agent Systems Through Model Context Protocol: Architecture, Implementation, and Applications.” ArXiv abs/2504.21030 (2025): n. Pag.
Hasan, Mohammed Mehedi, Hao Li, Emad Fallahzadeh, Gopi Krishnan Rajbahadur, Bram Adams and Ahmed E. Hassan. “Model Context Protocol (MCP) at First Glance: Studying the Security and Maintainability of MCP Servers.” ArXiv abs/2506.13538 (2025): n. pag.
Executive Analysis, Research, & Talking Points
Threat Modeling ASI02: The MCP Connection
So how can you threat model something so encompassing–especially when it’s behaving within its authorization? One answer lies in ASI02’s relationship to MCP servers.
