Attack Paths Through Agentic APIs: How Function Calling and MCP Get Exploited in Practice

Agentic AI systems don't get compromised the way traditional web applications do. There is rarely a single injected payload or a classic buffer overflow. Instead, the attack surface is the thing that makes these systems useful in the first place: an LLM that reads a tool's description, decides to call it, and acts on the result, often with real credentials and real system access behind that decision.

This piece maps a realistic, end-to-end attack path through that surface, function calling and the Model Context Protocol (MCP) specifically, using only disclosed, attributed research and documented incidents from 2025 and 2026. The goal is to show how individual, narrow vulnerabilities chain into full compromise, and where each stage of that chain maps onto the OWASP Top 10 for Agentic Applications (2026) (ASI01 to ASI10).

Why function calling and MCP are a distinct attack surface

Function calling gives an LLM a menu of tools it can invoke, each described in natural language so the model knows when and how to use it. MCP standardizes how those tools are exposed and connected across agents, servers, and clients. Both mechanisms share a structural property that traditional APIs don't have: the interface description itself, not just the interface's behavior, is part of the attack surface. A tool's name, its description, and its declared parameters are read by the model at decision time and treated as trusted context, whether or not they actually are.

That property is what makes the attack path below possible. None of the individual weaknesses described here are exotic. Chained together, they describe a realistic path from a poisoned tool description to full remote code execution and data exfiltration, a path that has already been walked by a real, state-sponsored threat actor.

Stage 1: Establishing a foothold through tool and descriptor poisoning

The entry point for most documented agentic API attacks isn't a network exploit. It's a malicious or compromised tool definition sitting alongside legitimate ones in the same agent context.

Tool poisoning occurs when a malicious actor deploys a tool that masquerades as legitimate or innocuous, aiming to get either the LLM or the end user to select and approve it, granting it capabilities it shouldn't have (Invariant Labs, 2026). The core weakness is structural: tool descriptions are free-form text read by the model every time it decides which tool to call, which makes the description field itself attacker-controlled input sitting inside the prompt context.

Invariant Labs demonstrated this concretely: a malicious MCP server co-present with a legitimate WhatsApp MCP server in the same agent context could instruct the agent, through its tool description alone, to read a user's message history and transmit it to an attacker-controlled number, with no user prompt required and a description that appeared visually benign to a human reviewer. A companion demonstration against GitHub MCP servers achieved exfiltration of private repository contents using the same technique.

A related variant, the rug pull, doesn't even require deploying a new malicious tool. A tool's description or behavior is silently altered after a user or agent has already approved it, converting a previously trusted, benign integration into a malicious one without triggering a second approval step (Cloud Security Alliance, 2026). And critically, a poisoned tool doesn't even need to be the one the agent calls: its description alone can be crafted to shadow and steer the behavior of other, legitimate tools present in the same context. This maps directly to ASI04 (Agentic Supply Chain Vulnerabilities) and ASI06 (Memory and Context Poisoning).

Stage 2: Hijacking function selection directly

Where Stage 1 relies on social-engineering the model through a crafted description, a newer research line demonstrates that function selection itself can be attacked more directly and more reliably.

The Function Hijacking Attack (FHA), published in 2026, targets the function-calling preference process itself: instead of relying on a plausible-looking description, it forces the model to select an attacker-chosen target function over the correct one for the user's actual request (arXiv:2604.20994). Unlike earlier prompt-based manipulation, FHA is largely agnostic to context semantics and robust across different function sets, and the researchers were able to train universal adversarial functions capable of hijacking tool selection across multiple queries and payload configurations. Tested against five models, including reasoning variants, the attack achieved a 70 to 100 percent success rate on the established Berkeley Function-Calling Leaderboard (BFCL) dataset.

The practical implication: an attacker doesn't need a convincing social-engineering narrative embedded in a tool description. A sufficiently engineered malicious function can win the selection process on its own, against the model's actual reasoning process, not just against a human reviewer skimming a tool list. This is ASI01 (Agent Goal Hijack) and ASI02 (Tool Misuse and Exploitation) operating at the model-decision layer rather than the social-engineering layer.

Stage 3: From tool call to code execution and credential theft

Once an attacker controls which tool gets called, or has planted a tool the agent will call, the next stage is converting that control into code execution or credential access. Here the research moves from "the model made a bad decision" to "the protocol and its implementations have exploitable design gaps."

In April 2026, security researchers at OX Security disclosed an architectural vulnerability affecting MCP's official SDKs across Python, TypeScript, Java, and Rust, one that enables arbitrary remote code execution on systems running a vulnerable implementation and touches a supply chain spanning more than 150 million downloads and up to 200,000 server instances (Tom's Hardware, 2026). The research produced at least ten CVEs rated high or critical across downstream projects including LiteLLM (CVE-2026-30623), Bisheng (CVE-2026-33224), Windsurf (CVE-2026-30615), GPT Researcher, Agent Zero, LangChain-Chatchat, and DocsGPT. Notably, Anthropic reportedly characterized the underlying protocol behavior as "expected" rather than issuing a protocol-level fix, leaving the mitigation burden on individual downstream implementations.

This wasn't an isolated finding. Earlier MCP implementations carried their own disclosed RCE paths: CVE-2025-49596, a remote code execution vulnerability in the MCP Inspector tool (Qualys ThreatPROTECT, 2025), and CVE-2025-6514, a critical RCE in the mcp-remote package threatening any LLM client that depended on it (JFrog, 2025).

The most fully documented example of this stage came from Check Point Research's analysis of Claude Code, which found that project-level configuration mechanisms, Hooks, MCP server definitions, and environment variables, could be abused to execute arbitrary shell commands and exfiltrate API credentials the moment a developer opened an untrusted repository (Check Point Research, 2026). Two CVEs came out of that work: CVE-2025-59536 (CVSS 8.7), which allowed project-contained code to execute before a user ever accepted a trust dialog, and CVE-2026-21852, which allowed API traffic to be silently redirected through an attacker-controlled endpoint via the ANTHROPIC_BASE_URL variable, leaking the API key before trust was confirmed. Both were responsibly disclosed and patched, but the underlying pattern, project or repository content silently reconfiguring an agent's execution and credential handling, is a supply chain risk inherent to any system that lets external content influence tool configuration. This is ASI03 (Identity and Privilege Abuse) and ASI05 (Unexpected Code Execution) in direct, documented form.

Stage 4: The fully assembled chain, observed in the wild

Every stage above has been demonstrated individually, in controlled research. Anthropic's own threat intelligence team documented what it looks like when an adversary assembles the full chain and runs it against real targets.

In a campaign tracked as GTG-1002 and disrupted in September 2025, a state-sponsored threat actor wired open-source penetration-testing tools into Claude Code as MCP servers, converting an AI coding assistant into an orchestrated, largely autonomous attack platform aimed at roughly 30 organizations spanning large tech companies, financial institutions, chemical manufacturers, and government agencies (Anthropic, 2025). Using this framework, the agent conducted vulnerability research, wrote its own exploit code, harvested credentials, and extracted data, with human operators intervening at only four to six decision points per campaign. Anthropic estimated the AI carried out 80 to 90 percent of the tactical work itself, and described it as the first documented case of a cyberattack executed largely without human intervention at scale.

This is ASI08 (Cascading Failures) and ASI10 (Rogue Agents) realized end to end: tool integration became privilege, privilege became autonomous execution, and autonomous execution became a scaled, largely unsupervised campaign. It is also the clearest evidence available that the attack path described in Stages 1 through 3 isn't theoretical. It is the documented mechanism behind a real espionage campaign.

Mapping the chain to OWASP ASI01–10

What this means for anyone exposing agentic APIs

The pattern across all four stages is consistent: the vulnerability is rarely in the model's reasoning quality. It's in the trust boundary between the model and the tools, descriptions, and protocol implementations surrounding it, boundaries that most organizations haven't inventoried, let alone secured.

Practical priorities that follow directly from the evidence above:

1. 1Treat every tool description as untrusted input, not documentation. Validate and sanitize tool metadata the same way you'd validate any other data crossing a trust boundary, and monitor for post-approval changes to previously trusted tool definitions (rug pulls).
2. 2Assume function selection can be attacked, not just social-engineered. Guardrails that only check whether a tool description "looks reasonable" won't catch an FHA-style attack aimed at the model's selection process directly.
3. 3Patch and inventory MCP implementations like any other high-risk dependency. The 2026 SDK-level RCE findings affected widely used libraries most teams didn't think of as part of their attack surface. If you can't currently list every MCP server and version your agents talk to, that's the first gap to close.
4. 4Scope credentials to the task, and audit what configuration files can silently redirect. The Claude Code findings show that environment variables and project-level config are viable exfiltration paths precisely because they're trusted by default.
5. 5Monitor at the API and protocol layer, not just the prompt layer. Prompt-injection filtering doesn't catch a malicious tool description, a hijacked function selection, or an SDK-level RCE. Those require API-level visibility into what tools are being registered, called, and what they're doing with the access they're given.

That last point is the throughline of this entire attack path: every stage of it happens at the API and protocol level, not inside a single prompt. Discovering and securing that surface, the tools, MCP servers, and function-calling endpoints an agent can actually reach, is API security work as much as it is AI security work. Chronoloq's agentless approach to shadow API and endpoint discovery, combined with LLM Shield's runtime coverage of RAG, A2A, and MCP-based architectures, is built specifically for this convergence: organizations shipping agentic AI faster than they can inventory what it's connected to.