In this blog we discuss several threat vectors that MCP & Function Calling expose and how security professionals can work to address them.

An attacker gains control via available functions (rogue code execution)

 

What the risk is

When an LLM is given a set of function definitions (names, schemas, parameters, descriptions), the model decides *which* function(s) to call and with what arguments. If the provided function set includes powerful capabilities (e.g. code execution, file system access, network access, process spawning), an attacker can leverage prompt injection, coercion, or crafted inputs to get the LLM to call a “rogue” function or abuse valid functions in dangerous ways.

 

Real‑world examples

In the paper “The Dark Side of Function Calling: Pathways to Jailbreaking Large Language Models” the author demonstrates a “jailbreak function attack” in which prompts are crafted so that the model uses allowed function‑calls (with dangerous or misused argument content) to violate safety policies. The success of these attacks is very high (>90%) across several leading LLMs tested.

Implications

• A single misplaced or over‑permissive function can allow attackers to run arbitrary code.
• Even functions that seem benign (e.g. logging, data transformation) can be abused to exfiltrate data, change state, or escalate privileges if their arguments are not tightly validated.
• Attack surface increases as more tools/functions are exposed, especially those that interact with critical infrastructure (file systems, databases, OS internals, network endpoints).

 

Exposure of functions list such via middleware leaking what tools are available

 

What the risk is

If middleware, orchestrators, or other components exposed to or controlled by customers or third parties expose which functions or tools are registered and available (e.g. function names, descriptions, metadata), attackers gain reconnaissance: knowing what’s possible. That knowledge can allow crafting prompts to call specific functions, target privileged ones, or even craft arguments to exploit those functions.

Additionally, exposure of the function list can leak intended architecture, internal logic, or privileged capabilities (administrative, privileged APIs) that should be opaque.

Real‑world examples

In the “MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits” (Radosevich & Halloran, 2025), researchers showed that some MCP servers expose tools in their default server configurations which can be coerced to perform malicious code execution, remote access control, and credential theft. Exposure of tool metadata is part of what makes these attacks possible. 

The paper “We Should Identify and Mitigate Third‑Party Safety Risks in MCP‑Powered …” (Arxiv) addresses how third‑party service providers, by virtue of exposing standard interfaces under MCP, may become a weak link: adversarial providers could leak or misuse their capabilities, or malicious service providers could be used in cascading attacks. 

 

Implications

• Attackers with knowledge of available functions can tailor prompt injections more precisely.
• Even if only non‑privileged functions are exposed, chains of functions may combine into more dangerous behaviours.
• Tools that were meant to be internal or administrative may accidentally be exposed via over‑broad permissions or misconfigured metadata.

 

Observation & manipulation (man‑in‑the‑middle) on MCP or function calling channels

What the risk is

Because function calling and MCP tool invocations are, at base, API calls (often via JSON, over HTTPS / network channels), traffic revealing function names and parameters may be observable in network traffic. An attacker who can intercept or modify these messages (e.g. via MITM, compromised network components, or logging misconfigurations) may:

• Learn which functions are used / available
• Modify arguments (“poisoned parameters”) so that valid function calls are made but with malicious inputs
• Insert or change which function is invoked, or insert payloads into parameters that cause unintended (rogue) behaviour

This is particularly dangerous for MCP, because MCP standardises connectivity: clients, servers, tool descriptions, etc., may carry function names and schemas in metadata or in-flight messages. Attackers who can tamper with those could ‘steer’ the system.

Real‑world examples

• The MCP Safety Audit (2025) shows that attackers may coerce LLMs into calling tools from MCP servers with manipulated parameters, leading to code execution, remote control, credential theft. While not all via “network‑MITM”, some exploit parameter manipulation via input. 

• Another example: Researchers have detailed Tool Poisoning Attacks (TPA) in MCP systems, where tool descriptions (which are communicated to the LLM/client) are embedded with hidden malicious instructions—these are not visible to human users, but visible/perceivable by models. Such embedded instructions can modify how the tool behaves or how arguments are treated. 

• A more general analogue: traditional MITM or API proxy attacks in function or plugin‑enabled LLM systems, when traffic or metadata is logged or not encrypted properly, or where endpoints are misconfigured.

 

Implications

Sensitive details about functions/tools leak across network or logging channels.

Attackers can shift argument values, introduce malicious parameters (e.g. shell escape strings, path traversal, SQL injection) into function calls.

Without validation or signature enforcement, the downstream host executing tools may perform unwanted action.

 

Systemic Risks with MCP & Function Calling

Some of the above threats combine or amplify.

Prompt Injection + Function Exposure

Knowing what functions exist, an attacker can inject prompts that lead to those being called.

 

Tooling / Server Misconfiguration

Default or sample configurations may include tools that are too permissive.

 

Third‑party tools or providers

Using MCP servers or function‑providers you do not fully control increases risk — e.g. if a third party becomes malicious or is compromised.

 

Conclusion

Function calling and MCP are powerful enablers that extend LLMs beyond passive text generation into actionable agentic systems. But with power comes risk. Many of the dangers are subtle:

• Exposure of function or tool lists via metadata leaks

• Argument poisoning, tool misuse, or chain of tools causing dangerous effects

• MITM or network intercepts exposing or modifying function calls

 

From what the research shows, many systems today are insufficiently hardened. Attacks like jailbreak function or MCP tool coercion are demonstrably possible with high success rates. For highly regulated or high‑security environments, ignoring these risks could lead to breaches, data loss, compliance failures, or worse.

Turning off functionality if not needed, strictly controlling what is exposed, validating inputs, sandboxing executions, monitoring aggressively, and applying the principle of least privilege throughout are non‑negotiables.

 

References

[1] “The Dark Side of Function Calling: Pathways to Jailbreaking Large …” https://arxiv.org/html/2407.17915v2?utm_source=sandgate.io 

[2] “CVE-2025-3248: Unauthenticated Remote Code Execution in Langflow” https://www.keysight.com/blogs/en/tech/nwvs/2025/06/29/cve-2025-3248-langflow-unauthenticated-code-validation?utm_source=sandgate.io

[3] “MCP Safety Audit: LLMs with the Model Context Protocol Allow Major …” https://arxiv.org/html/2504.03767v2?utm_source=sandgate.io

[4] “We Should Identify and Mitigate Third-Party Safety Risks in MCP-Powered …” https://arxiv.org/pdf/2506.13666?utm_source=sandgate.io

[5] “Systematic Analysis of MCP Security – arXiv.org” https://arxiv.org/pdf/2508.12538?utm_source=sandgate.io

[6]: “Meta’s Llama Framework Flaw Exposes AI Systems to Remote Code Execution …” https://thehackernews.com/2025/01/metas-llama-framework-flaw-exposes-ai.html?utm_source=sandgate.io