What is MCP Security Testing for Tool Calls?

MCP security testing for tool calls involves adversarial testing to ensure that the arguments that an AI agent passes to tool calls, as well as what the AI agent accesses with the tool calls and the order in which the agent performs actions, can't be manipulated, hijacked, or abused through the MCP layer. It is different from testing the model's predictions. It tests the ability of an agent to act after getting his or her hands on real credentials, real tools, and real ability to act, and that's where the production risk lies.

Why Testing Tool Calls Is Different from Standard LLM Safety Evaluation

The majority of AI security tools were designed to address the question of whether the model "says something it shouldn't say. That question remains, but as soon as a model gets tools, it's not the end of the story. Vulnerabilities of agentic AI tools are not to be found where dangerous text outputs are found, nor are they to be tested in the same way.

Prompt-and-Response Testing vs. Testing an Agent That Acts

In classic LLM evaluation, a prompt is sent to the LLM, and the response is examined. Closed loop: text in, text out, judge the text. As soon as an agent communicates with a tool via the MCP, it breaks that loop, since whatever it is that matters isn't a sentence; it's a query to the database, a write to the file, a payment or an email sent to a real inbox. A model can generate a response that makes sense to the user, and the underlying tool can do something that perhaps the user didn't expect. Testing must follow the action, not just the words that precede it, and trace what tool was used, the arguments, the system to be used, and whether the sequence is correct and whether it matches the intent.

The Four-Layer Agent Attack Surface: Application, Model, Tool/MCP, Data

Security teams that employ the "agentic red team" methods in 2026 tend to have a similar application layer (how the user and other systems interact with the agent), a model layer (where reasoning and following instructions occur), a tool or MCP layer (where the agent accesses external systems with real privileges), and a data layer (what is read, written, or exposed en route). Tool-call testing is a one-of-a-kind approach that is fully dedicated to that third layer. It's the layer where a compromised prompt becomes a compromised action and it's the layer that both traditional application security and traditional LLM evaluation missed – after all, neither was built to examine it.

What MCP Security Testing for Tool Calls Actually Checks For

Tool-call testing is not a single question, but a series of questions against all tools that an agent can find. Each of these attempts teaches how an attacker might exploit a given tool call.

Argument Injection and Intent-Beyond-Scope Tool Calls

Argument injection occurs when an AI agent is fed an argument to a tool call that the user did not mean for it to receive. This can be done in a variety of ways, including by a carefully crafted user prompt, through a poisoned document, or by chaining instructions. If a support agent is requested to "look up this order," the agent could be tempted to provide a wildcard that fetches all the orders for a given customer instead of just one. Testing for this involves deliberately designing inputs that expand scope and/or alter targets, or sneak additional parameters into a call, and seeing if the agent enforces the limitations it should. This is also where unauthorized tool calls are most frequent; not via some grand break-in but via a different agent that is quietly doing more than was scoped.

Indirect Prompt Injection via Tool Outputs and Retrieved Content

Not all attacks are presented in the user prompt. Indirect prompt injection testing emphasizes the content that an agent pulls and assumes as being accurate: a web page, a support ticket, a PDF, a calendar invite, or output from another tool call. If any of that content includes instructions, and the agent can't reliably distinguish instructions from data, the attacker doesn't even have to have direct access to the conversation. They all need to drop their payload where the agent will find it. Seeding retrievable content with injection payloads and monitoring for changes in the agent's downstream tool calls when testing this path.

Semantic Tool Poisoning and Malicious Tool Descriptions

Semantic tool poisoning focuses on the definition of the tools, not on the conversation itself. The description, parameter names and/or the documentation of an MCP tool may contain instructions/guidelines that an agent reads as guidance without it being noticed by a human looking through the tool list. A tool description that silently passes the user's session token in the request is an attack; it is not a bug report. Assessing malicious tool descriptions involves not only examining whether the agent behaves differently when the description is different, but also examining what the agent actually says to the model when it's connected to it.

Multi-Step Exploit Chains Across Chained Tool Calls

It's possible to have a reasonable individual tool call, and still have a serious problem once they're linked together. Multi-step chains of exploits could launch with a low-level tool that was able to expose an identifier, then feed that identifier into a second tool that was not designed to have been accessed via that route, and culminate in a third step that exfiltrated data or enabled an action that no single step would have been a red flag for. Testing any individual tool will not address this. They must simulate multi-turn, multi-tool sequences as a real attacker would, with one turn unlocking the next.

Confused Deputy and Over-Broad Credential Use in Tool Calls

A confused deputy problem occurs when an agent has a credential that has a wide authority and is led to use it to act on a request that did not satisfy the authority of the credential. Confused deputy tool calls are particularly prevalent in multipurpose (MCP) environments where a single server-side token is used for all the users' tool calls, meaning that the agent is effectively a proxy for the user making the call, and will do what it's told without much question. This is similar to OWASP's definition of excessive agency: a system gives an agent more standing capability than any one specific task. Testing: determining if an agent requires per-request authorisation, or if it only passes along what credentials it has in its possession.

The Frameworks Tool-Call Testing Should Map To

When running adversarial tests, without mapping the findings to a known framework, conclusions become difficult to prioritize and even more difficult to defend to an auditor. Several frameworks and practitioner resources like the Cloud Security Alliance's Agentic AI Red Teaming Guide have emerged to establish the shared vocabulary that is being coalesced around this space.

OWASP Top 10 for Agentic Applications and Top 10 for LLM Applications

Because the previous OWASP Top 10 for LLM Applications wasn't designed with acting systems in mind, the OWASP Top 10 for Agentic Applications for 2026 was created by a large community of security practitioners who wanted to list the risk categories that are specific to autonomous systems. The LLM list also plays a role here, especially the over-privileged agentic access to tools, as the more tools a model has, the lower its score on the agentic tests will be, regardless of the quality of the model's text output. A model-layer vulnerability can lead to a tool-layer vulnerability, and vice versa, so tool-call testing should test against both lists.

MITRE ATLAS

MITRE ATLAS contains tactics and techniques actual adversaries use against AI-enabled systems – just like security teams already do for traditional threat modelling in a structured ATT&CK format. ATLAS has been recently updated to provide agent-specific techniques for tool invocation abuse and poisoned tool publication, and so is a helpful common language for describing the sequence of events that led to the occurrence of a tool-call exploit, rather than just that it occurred. The mapping to the IDs of ATLAS techniques also simplifies tool-call testing results that need to be inserted in an existing SOC and SIEM workflow.

NIST AI RMF and the Generative AI Profile

The NIST AI Risk Management Framework and its Generative AI Profile supplement provide organizations with a governance framework that includes four functions: Govern, Map, Measure and Manage. It's not a substitute for technical testing, but it provides tool-call results a place in a risk register that regulators, boards and procurement teams are familiar with. As ISO 42001 outlines the requirements for an AI management system, many organizations applying for ISO/IEC 42001 certification rely on the NIST profile as the operational layer below it, as the NIST profile outlines the functions that constitute the day-to-day risk work performed. When test results are expressed in this way, it is a technical finding that becomes evidence a compliance program can act on.

Why Most Red Teaming Tools Stop at the Model and Miss the Tool Layer

There are numerous AI red teaming tools available. Very few of them look beyond the model's output text to what the agent did after using a tool. It's the gap agentic AI tool call vulnerabilities tend to hide in, and it's the gap Akto's agentic red teaming was designed to solve by simultaneously testing tools, MCP servers, and agents instead of just the model.

The MCP Supply Chain Gap

From a functional perspective, the MCP servers form a new software supply chain that is being adopted at a rate that is quicker than the rate of adoption for tooling to secure the supply chain. Access control is not mandatory for protocols and is not required for any exchange; the May 2026 NSA advisory on MCP security design made that point clear: there is no enforced method of verifying what a tool is allowed to access, nor is there any requirement for exchange to have access control. That "gap" is not hypothetical. CVE-2025-49596 is a critical remote code execution vulnerability found in the MCP Inspector developer tool, which allowed an unauthenticated attacker to execute arbitrary code without requiring the developer to open a malicious webpage or click on a malicious link in an email. More recently, third-party tools such as Tencent's AI-Infra-Guard have been developed specifically for auditing MCP servers and agent skills for this type of supply chain risk, reflecting widespread industry awareness of such a gap, albeit not yet filled by individual vendors. MCP's supply chain testing should cover all the servers that an agent can reach, not only those that they have built in-house.

Why "More Jailbreak Prompts" Isn't the Same as Testing Tool-Call Behavior

There are a ton of jailbreak prompts in a large library – they tell you if a model can be persuaded to say something unsafe. It does little to indicate whether that same model, used with actual tools, will follow the instructions. There is no guardrail to prevent dangerous text, and two agents can score the same on a prompt-based benchmark, but perform widely divergent behaviors when tool access is added. Assessing tool call behavior involves actually wiring up the tools, executing the agent against them and observing downstream.

How MCP Tool-Call Security Testing Is Actually Run

Such testing is more of a red team session than a benchmark run. It begins by knowing what type of agent can access it, and then attempts to access it in a manner similar to an actual attacker.

Mapping the Agent's Full Tool Graph

Testers must have a full understanding of the graph mapping for tools before they start running a test against an adversary: all of the tools that the agent can call, all of the MCP servers behind the tools, all of the credentials and scopes associated with each server, and all of the paths from which the output of one tool is the input to another. Teams add new tools and tools enable other new tools, and it's not uncommon to see access to tools that no one can remember approving and, in some cases, no one even knows where to find the original approval for certain tools. If this map wasn't there, the test would be full of the tools that the team did expect to be risky, or it would lack the tools that nobody thought to test.

Dynamic, Adaptive Adversarial Testing vs. Static Prompt Replay

Static prompt replay is a known set of prompts that are replayed to a system and checks for known-bad responses. It can detect regressions, but it will not detect anything new, and agents change their behaviour far too frequently, so yesterday's safe configuration can be today's exposed one. Dynamic adversarial testing, on the other hand, makes the next attempt in accordance with the agent's response to the previous one, following probes, making adjustments to arguments, and following paths that do not seem to produce results, just like a human attacker. Meaningful MCP red teaming is not a checklist; it's a process of dialogue between the red team and the system being tested.

Turning Confirmed Exploits into CI/CD Release-Blocking Regressions

If an exploit is confirmed and not retested, it will come back. When a vulnerability is confirmed, it should be converted to an automatic CI/CD security regression test to preclude any holes that may be re-opened by tool change, new integration or system prompt update. This is the difference between a one-time assessment and a testing program; the exploit is no longer a memory but a gate.

From Findings to Evidence: Reporting and Severity Scoring

If it's just a "tester's note" finding, it isn't going to help anyone outside the security team. Evidence that a CISO, auditor, or customer's security questionnaire can actually use is required from tool-call security testing.

Auditor-Ready Reports and Severity Mapping

Security testing of tools is not just a pass/fail affair. It records the exact tool, argument manipulation or chain that provoked the problem, and it includes reproduction steps, impact on the business if the path had been exploited in production, and a severity rating that has been related to a well-known scale that enables this finding to be presented side by side with traditional vulnerability data without requiring translation. That mapping is what enables the findings from the tool call to be associated with one of the following: An ASI category from the OWASP Agentic list, A technique ID from the ATLAS list, A NIST risk register entry and all referencing the same finding.

Continuous Testing vs. One-Time Assessment

A system's risk is assessed once, and it is not static in the sense of an agentic system. Tool descriptions are edited, new MCP servers are added, prompts are tuned, and all of those changes could open a path that has been closed by the testing. The only kind of security testing of tools that actually keeps up with how quickly agentic systems change in production is continuous tool-call security testing, which is conducted every time a meaningful change occurs.

How Akto Approaches MCP Security Testing for Tool Calls

Akto's agentic security platform is centered around the attitude that an agent's tools are just as much a part of the attack surface as are the prompts themselves. It begins with automatic discovery of all the MCP servers, tools, and agents within an environment, including the ones deployed by individual teams without a formal inventory database, and continues with a constant red-teaming of all the discovered surface by probing them with adversarial techniques like tool poisoning, prompt injection, jailbreaking, and argument-level manipulations that generate unauthorized tool calls. Results are compared to the OWASP LLM, Agentic and MCP top 10 lists and MITRE ATLAS, allowing results to be acted upon immediately without translation. If it's a real exploit path, Akto also introduces runtime guardrails which can stop the same class of tools from being misused in production, thereby completing the loop from finding a vulnerability in a tool call to stopping it in production.

Final Thoughts: MCP Security Testing for Tool Calls

Tool calls are where agentic AI risk turns into real-world impact, which is exactly why they deserve testing that goes beyond a model's text output. As MCP adoption accelerates and the NSA, OWASP, and MITRE all move to formalize this attack surface, treating tool-call testing as optional is no longer a defensible position for any team shipping agents into production. Akto's agentic security platform discovers every MCP server and tool an agent can reach, continuously red-teams that surface for the exact vulnerabilities covered here, and enforces runtime guardrails against confirmed exploit paths. Book an MCP Security demo to see how Akto tests tool-call behavior across your agentic and MCP-connected systems before an attacker does.

FAQs: MCP Security Testing for Tool Calls

What is MCP security testing for tool calls?

It's not testing the output of the model; it's adversarial testing of the calls the AI agent makes through the MCP layer - the arguments, targets, and sequencing that an agent uses to make a call through the MCP layer.

How is testing tool calls different from standard LLM safety evaluation?

The standard LLM evaluation is based on the quality of the text output. The intention of tool-call testing is to test what the agent does after calling a tool, because saying something safe could lead to something unsafe.

What is argument injection in the context of AI agent tool calls?

It occurs when an attacker alters the parameters passed to a tool call in a message/poisoned content so that the call runs in a different scope or target than the agent expects.

What is semantic tool poisoning?

An attack in which the description or documentation of a tool and not the actual tool contain instructions that change the way in which the agent uses the tool or other tools that the agent uses around the tool.

How does indirect prompt injection lead to unsafe tool calls?

If a webpage or document is treated as trusted by an agent, it can be redirected via instructions embedded in that content, without the user typing anything malicious, and change which tools it then calls next.

What is the four-layer agent attack surface referenced in 2026 testing frameworks?

The majority of the 2026 agentic testing methodologies divide the attack surface into an application layer, model layer, tool or MCP layer, and data layer; their focus is specifically on 3rd: tool-call testing.

Why do most AI red teaming tools miss risks at the MCP and tool-call layer?

Many red teaming tools were created to evaluate prompts and responses, not to wire up real tools and watch downstream behavior, so they can't observe a vulnerability until an agent does something.

What frameworks should tool-call security testing map findings to?

The OWASP Top 10 for Agentic Applications, the OWASP Top 10 for LLM Applications, MITRE ATLAS, the NIST AI RMF and its Generative AI Profile, and, for governance, ISO/IEC 42001 are the main reference points.

What did the May 2026 NSA advisory reveal about MCP tool-call vulnerabilities?

The NSA's advice was that access control is not mandatory at the protocol level and no identity is required to be validated, that there is no enforced role-based access and that in instances of production MCP deployment, there is little or no mapping from session to identity.

What is a confused deputy attack in the context of tool calls?

It's when an agent has a much broader credential and can be manipulated to use on a request that shouldn't have been eligible, and that makes the agent an unwitting proxy for the attacker.

How does dynamic adversarial testing differ from static jailbreak prompt replay?

Static replay plays a series of pre-known prompts and verifies known responses. Dynamic testing: adapts each attempt based on the agent's previous response - probes are chained and adjusted just as a real attacker would.

What does it mean to "map an agent's tool graph" during testing?

It involves documenting all tools, MCP servers, credentials and connections that an agent can interact with, along with describing how the output of one tool can be used as the input to another before the adversarial testing starts.

Can tool-call security findings be turned into automated CI/CD regression tests?

Yes. If an exploit is confirmed, it can be turned into a regression test that would be executed on every new build, and all changes, such as a changed tool description or a new integration, can't be made without reopening a closed vulnerability.

What does an auditor-ready MCP security testing report typically include?

Usually includes the details of the tool and argument used, steps to reproduce the issue, impact on business, and a rating of the severity level of the tool and argument, rather than a simple pass or fail label, that is based on a known framework.

How does Akto test for tool-call vulnerabilities in agentic and MCP-connected systems?

Akto identifies MCP servers, tools and agents throughout an environment, constantly red-teams them for tool poisoning, prompt injection and argument-level manipulation, correlates with OWASP and MITRE ATLAS and imposes run-time security constraints on identified known tools that exploit.