MCP Tool Call Security: The Agent Tool Surface Is the Attack Surface

When the Agent Becomes the Caller, Where Does the Security Boundary Lie?

MCP (Model Context Protocol) allows AI Agents to call external tools—reading files, querying databases, calling APIs. This is precisely its value, and also precisely its most easily overlooked risk.

When most teams deploy Agents, they focus on model capability, tool coverage, and response quality—yet few seriously answer one question: Who decides which tool the Agent calls and with what parameters?

The answer is the Agent itself. It decides its tool-calling strategy based on context assembled from various sources—user input, retrieved documents, previous conversation turns. And many of these context sources are outside your control.

MCP (Model Context Protocol) is an open-source protocol standard released by Anthropic in late 2024, designed to provide a unified connection method between LLM applications and external data sources and tools. It is often compared to "the USB-C interface of the AI world." Before MCP, each AI application that needed to connect to external tools typically had to write its own adapter code, resulting in poor tool reusability and a fragmented ecosystem. By defining standardized server and client interaction specifications, MCP allows tool providers to implement just one MCP Server, which any Agent supporting the protocol can directly call.

This design dramatically lowers the cost of extending Agent capabilities, but it also means the Agent dynamically acquires and calls a large number of tools that are not part of its own codebase at runtime. Once a tool exposed by an MCP Server has write operations or high-privilege capabilities, the consequences of the Agent being manipulated into misuse are amplified. Understanding MCP's "protocol neutrality"—it only handles connection, not authorization or auditing—is the prerequisite for understanding the security proposition of this article.

A Tool Is an API Endpoint with a Model Attached

Suppose your MCP server exposes a tool called execute_query that allows the model to pass in arbitrary SQL statements. From a security perspective, this is not a "tool integration" but a SQL injection vulnerability with an LLM as the middleman.

The traditional approach to injection defense is clear: isolate untrusted input from the query. But in the Agent scenario, the untrusted input is exactly the context the model reads, and the query statement is precisely what the model generates. Firewall rules and form validators have no place on this path.

This means an attacker does not need to directly touch your database. He only needs to embed a carefully crafted instruction in some content the Agent can read, potentially inducing the Agent to generate a malicious query. This is a completely new form of injection attack that traditional security tools cannot cover.

Indirect Prompt Injection is defined relative to direct injection: direct injection involves a user directly entering a malicious instruction in the current conversation; indirect injection hides the malicious instruction in external content the Agent will read, such as web pages, PDFs, database records, code comments, or even tool return results. When the Agent retrieves this content to complete a task, the malicious instruction enters the model's decision-making process as part of the context, and the model may mistake it for a legitimate instruction and execute it.

The danger of this attack lies in the absence of a direct interaction channel between attacker and victim. The attacker only needs to plant an instruction in some public web page or shared document and wait for it to be retrieved. Traditional mechanisms such as input filtering and WAF typically only scan user input and are nearly powerless against indirect injection. Therefore, injection defense in the Agent scenario must cover "all data sources that enter the model context," not just the user input box.

The Only Criterion for Determining Whether an Agent Is Secure

To determine whether an Agent's tool calls are secure, you only need to answer one question:

Can the model be influenced by users, retrieved content, or conversation history to call tools in ways you did not anticipate?

If the answer is "yes"—and for most Agents, the answer is "yes"—then the tool's permission management needs to be reviewed according to the standards of a public API endpoint. Assume that untrusted people can reach it, because in practice they actually can.

The practical value of this judgment framework is that it pulls Agent security back from the abstract discussion of "AI alignment" to the engineering practice of "API permissions." You don't need to solve the alignment problem to protect tool calls; you just need to protect them the way you protect APIs.

Three Lines of Defense Missing from Most Agent Deployments

In most Agent deployments examined in practice, the following three control measures are commonly absent:

Per-Tool Authorization Scoping

An Agent should only receive the tool permissions needed to complete the current task, not full access to all registered tools. A summarization tool does not need shell access. But in actual deployments, teams often enable all tools for the Agent simply for debugging convenience—which is a serious privilege escalation problem in production environments.

The Principle of Least Privilege is one of the cornerstones of security engineering, first proposed by Saltzer and Schroeder in 1975. It requires that any subject only receive the minimum set of permissions necessary to complete its current task, and that permissions be promptly revoked after the task ends. In traditional systems, this principle is usually implemented through roles, scopes, and tokens.

In the Agent scenario, implementing least privilege is more difficult because the Agent's tool requirements are dynamic and determined by the model itself. Feasible approaches include: defining independent scopes for each tool and binding them to specific tasks; granting tool permissions at the session level rather than the Agent level; introducing human confirmation or secondary authorization for high-risk tools (such as shell, file writing, SQL execution); and setting limits on tool call frequency and concurrency to prevent a single prompt injection from triggering large-scale operations. Together, these measures form the first layer of "defense in depth."

Input Validation Before Execution

Before the tool runs, you should check whether the passed parameters fall within the range the tool should accept. Checking after it runs is not defense—that's incident response. The difficulty here is that the parameters passed by the Agent are dynamically generated natural language converted into structured data, requiring a specially designed validation layer.

Full Tool Call Audit Logging

Record every tool call, the parameters passed, and the complete context that produced the call. Without context, logs can only answer "what happened" but cannot answer "why it happened"—which is precisely what all security reviews truly care about. Audit logs without context are nearly useless in post-incident forensics.

Old Problem, New Caller

These three controls are not new in themselves. They are exactly the security measures you already implement on APIs. The only change the Agent brings is this: the caller has changed.

In the past, the caller of an API was an authenticated user or service; now the caller of an API is a model that may be manipulated by adversarial input. API protections still apply—they just need an adaptation layer between the model and the API to ensure the model's output undergoes validation as strict as that for a human user before reaching the real API.

Your Agent tool surface is your attack surface. It deserves to be treated as one.

One-line Summary

MCP lets Agents call tools autonomously, but the security essence is an API permission problem with an LLM middleman.

Paragraph Summary

The article points out that the MCP protocol allows AI Agents to autonomously decide which tools to call and what parameters to pass—a convenience that is also its greatest risk. The author reframes the problem through one key lens: an MCP tool that allows arbitrary SQL input is essentially a SQL injection vulnerability with an LLM as the middleman; untrusted context such as user input, retrieved documents, and conversation history is exactly what the model bases its calls on, so an attacker can induce the Agent to perform malicious operations without touching the database. The core criterion for judging Agent security is only one—whether the model can be influenced by external input to call tools in unexpected ways. The article then identifies three missing lines of defense in most deployments: per-tool authorization scoping, pre-execution input validation, and full audit logs with context, emphasizing that these measures are essentially API security—only the caller has changed from a trusted user to a manipulable model.