MTGuard: Hybrid Analysis for Secure MCP Tool Calls in LLM Agents

Existing MCP tool defenses mainly inspect messages and cannot see system-level side effects at execution time.

• Scenario: The authors state that MCP has become the de facto standard for LLM agents to connect to external resources; untrusted or compromised tools can influence decisions and produce harmful side effects in the host environment.
• Limitations of existing work: The authors state that existing defenses mainly inspect prompts, conversations, tool metadata, call parameters, and textual results, and generally cannot observe execution-time side effects. They also state that traditional sandboxing or runtime monitoring cannot directly fill this gap: whether the same file access or network request is unsafe depends on the declared functionality, parameters, and task context.
• Core assumption: An effective defense must connect runtime side effects to the semantic context of the call. The authors believe that looking only at messages or only at low-level traces makes it hard to detect attacks whose declarations appear benign but whose execution is harmful, especially tool execution hijacking.
• Proposed approach: MTGuard acts as a standalone guard agent that performs combined static and dynamic analysis before, during, and after execution, and uses a tool behavior tree to represent the runtime behavior of a single call.
• Threat model:
  • Goal: Induce unsafe tool use, disrupt the intended task, or cause unauthorized effects in the host or external environment.
  • Entry points: Following MCP-SafetyBench, from one of the MCP server, MCP host, or user, with only one assumed compromised at a time. The server side can control metadata, descriptions, return payloads, or implementation; the host side can tamper with planning, orchestration, or message routing; the user side can control requests and user-provided files or external content.
  • Boundaries: Cannot directly compromise the defense and its trusted monitoring facilities. Excludes training-time attacks, weight tampering, compromise of the defense system itself, kernel-level compromise, attacks outside the call lifecycle, and collusion attacks that compromise multiple attack surfaces simultaneously.
  • Victim system: The target LLM agent using MCP tools. The defense must detect and deny unsafe calls while preserving benign and task-relevant calls.

The introduction and Related Work divide prior work into three categories; the experiments additionally specify baseline components and benchmarks.

• Message-level tool defenses: The introduction states that one group of defenses mainly checks user prompts, conversation history, tool metadata and descriptions, call parameters, and textual results, and can detect suspicious instructions or metadata inconsistencies, but generally does not observe system-level side effects at execution time. The authors mark this group as references [5, 7, 17, 18, 25, 33, 35, 36]; the introduction does not detail each work's approach.
• Content-level and agent guardrails: Related Work states that most guardrails perform content-level filtering, such as filtering harmful or violent output, and considers this insufficient for agents that depend on tool use and execution context. The authors name GuardAgent (Xiang et al., 2025) for access control over the target agent, and Liu et al. (2025) for anomaly detection on behavior messages. The authors state that these methods mainly rely on static messages or interaction traces and, because they do not incorporate execution-time dynamic behavior, have difficulty detecting tool execution hijacking.
• MCP package-level detection: The authors state that recent work detects malicious tools by inspecting MCP server packages; A.I.G (Tencent Zhuque Lab, 2025) uses an LLM agent to inspect packages. The authors state that such methods stop at the package level and do not perform runtime monitoring during agent execution, so they cannot provide fine-grained protection for actual calls, and their defensive effect is limited.
• Baselines and benchmarks: The experimental baselines are Agent-Aegis (Deng et al., 2026)'s Tool Call Governance (TCG, pre-execution checks of tool name and parameters) and Tool Result Inspection (TRI, post-execution scanning of returned text). Tasks come from MCP-SafetyBench (Zong et al., 2025)'s browser automation and financial analysis, plus the authors' host-side Tool Call Hook.

The authors position MTGuard as coupling protocol-level context with dynamic execution evidence across the entire call lifecycle, rather than only message checking, only package scanning, or treating runtime monitoring as a sandbox detached from semantics.

MTGuard acts as an external guard agent that intercepts the target agent's MCP calls: before execution it examines declarations, during execution it only collects evidence, and after execution it compares declarations against observations to decide whether to allow or deny. Figure 1 shows the three components and the deny/allow paths; Algorithm 1 is in Appendix A.

Problem setup

• The agent issues a call T under task context c and environment state e, and execution causes a state transition. The authors treat a call as unsafe if and only if the post-transition context or environment falls into an unsafe set: ĉ∈ C_usf∨ê∈ E_usf.
• The safe set consists of calls where neither falls into an unsafe set after the transition. M(T;c,e) approves T if it belongs to that set, and denies it otherwise.
• The lifecycle is divided into pre-execution, in-execution, and post-execution. The implementation in Section 3 and Algorithm 1 denies before dispatch or withholds results after completion. The introduction also mentions the ability to terminate a running tool; Section 5.1 lists selective online termination as future work, and Algorithm 1 has no in-execution adjudication.

Pre-execution parameter audit

• Collects conversation history, the current task (the most recent user message), tool name, call parameters, and the parameter schema from the target agent's registry.
• Free-text tool descriptions may contain adversarial instructions; they are removed during the audit, leaving only the tool name and parameter descriptions.
• First runs user-defined programmatic policies; any violation leads to denial. If passed, an LLM evaluates natural-language policies. The system prompt states principles, and the user prompt fills in the task, history, tool name, schema, parameters, and rules. Appendix D's Prompt 1 and Prompt 2 give the full prompts.
• If either path denies, a denial response is returned before dispatch; otherwise monitoring is started and the call is allowed.

In-execution monitoring and behavior tree

• The monitor does not make safety conclusions. The tool executes in a Docker sandbox; host-side eBPF attributes by cgroup v2. Tracking starts before forwarding and stops after the tool returns and the event stream is idle.
• Tracks processes already in the cgroup (long-lived workers may predate this call) as well as newly forked descendants. Collects process creation, execution, and exit; file open, delete, and rename; TCP connection-related events; and UDP DNS responses from port 53 within the target cgroup. The current implementation records file names without reconstructing absolute paths; DNS events that cannot be reliably attached to a process node are kept separately.
• The tool behavior tree has the declared call as its root, recording the call identifier, tool name, and parameters, with process and DNS branches below. File and network events are attached to the responsible process, and parent-child edges represent observed process creation relationships. The raw tree and execution results are passed to post-execution verification. Appendix C gives a simplified tree example.

Post-execution verification

• The verifier compares the tool name, schema, declared parameters against processes, files, network, DNS, and returned content, to detect behavior not visible from declarations alone, including host-side call hijacking.
• Before LLM verification, the behavior tree is simplified: process identities, executed commands, and file and network events that do not match noise rules are retained. The main filtered items are Python bytecode and import artifacts, frequently loaded shared libraries, and loopback traffic treated as internal sandbox traffic. The raw tree goes to code policies, and the simplified tree goes to the LLM. Overlong process and DNS records, and tool results placed in the prompt, are truncated; the paper does not give truncation lengths.
• Code policies still take priority, then the LLM. The LLM operates on allow-by-default: only clear inconsistency or clear policy violation leads to denial. The prompt requires a consistency check between declarations and observations and includes step-by-step analysis and few-shot examples. Appendix D's Prompt 3 and Prompt 4 give the full prompts. On denial, results are withheld and do not enter subsequent reasoning; the authors state this cannot roll back side effects that have already occurred. On approval, results are passed to the agent.

实验设置

• 智能体与环境：两个ReAct智能体，分别主要用Playwright MCP server和Yahoo Finance MCP server，并可使用filesystem、terminal、network-fetching等辅助server。每次最多20步。原型基于AgentScope，沙箱为Docker，追踪为eBPF。机器为Ubuntu 22.04、247 GB内存、一块Intel Xeon Platinum CPU。
• 案例：MCP-SafetyBench取30个浏览器案例和53个金融案例，共83个；再加16个host侧Tool Call Hook（每域8个），合计99个：server 62、host 26、user 11。论文称覆盖18个细类。点名的server侧包括tool poisoning、function overlapping、preference manipulation、tool shadowing、function-return injection、rug-pull；原host侧包括intent injection、data tampering、replay injection；user侧包括malicious code execution、credential theft、remote access control。
• Tool Call Hook：被攻破的派发层在执行前审计已检查声明之后、真正执行之前，把指定良性调用替换为terminal::run_command及未授权shell命令。每任务最多一次。每域8个载荷覆盖未授权文件访问、安全敏感文件探测和与持久化相关的修改。此处不写具体命令。
• 模型与基线：后端为DeepSeek-V4-Flash、DeepSeek-V4-Pro、GPT-5.6 Luna。文本策略审计在全部设置中用DeepSeek-V4-Pro，它也是三个后端之一。基线是Agent-Aegis的TCG与TRI的Python适配，在MTGuard执行收集的同一tool-call记录上重放。TCG查高风险shell、命令混淆，并加受保护路径和危险shell检查；TRI只检测返回文本，不改写结果。
• 指标与协议：DR为检出的不安全调用数除以不安全调用总数，分子来自执行前或执行后的拒绝。FPR为被错误拒绝的安全调用数除以安全调用总数。标签由各案例的execution-based evaluator按攻击成功签名判定；DR只计入被确认不安全的调用，分母随模型变化。拒绝记为反事实裁决，不阻断执行、不修改结果。论文未报告重复次数。
• 策略：执行前有7条确定性规则：敏感文件、危险shell、SSH持久化、偏离任务的可疑URL、被遮蔽的工具名、任务与ticker不匹配、重复导航；重复阈值设为3。执行前、后各有3条自然语言规则，限制与任务无关的凭据、shell初始化文件、SSH密钥和提权探测，拒绝偏离任务的端点，并要求ticker、目的地、网站与用户任务一致。代码规则先于LLM。

主结果

据Table 1，工具调用级总体DR为：

Swipe horizontally to read the table

配置	MTGuard	TCG	TRI
Browser / DS-V4-Flash	53.5%（23/43）	4.7%（2/43）	0.0%（0/43）
Browser / DS-V4-Pro	44.8%（13/29）	10.3%（3/29）	0.0%（0/29）
Browser / GPT-5.6 Luna	60.0%（15/25）	16.0%（4/25）	0.0%（0/25）
Financial / DS-V4-Flash	46.2%（18/39）	15.4%（6/39）	0.0%（0/39）
Financial / DS-V4-Pro	37.0%（17/46）	6.5%（3/46）	0.0%（0/46）
Financial / GPT-5.6 Luna	51.7%（30/58）	3.4%（2/58）	0.0%（0/58）

• 合计：作者报告六配置上MTGuard检出116/240，总体DR 48.3%；TCG检出20次，DR 8.3%；TRI在这些轨迹上为0.0%。摘要中的48.3%与8.3%和Section 4.2一致；48.3%是合计比例，不是六格的非加权平均。
• 作者解读：作者称优势在host侧尤其明显，因为监控和执行后核验能看到Tool Call Hook造成的声明与实际命令不一致；TCG只看见原始声明，TRI在结果文本里找注入类模式。
• 同表中的差别：user侧六格MTGuard均为100.0%，且与TCG相同，TRI仍为0.0%。server侧低于同表的host侧和user侧；浏览器上DS-V4-Pro的server侧为12.5%（2/16），是该来源下MTGuard的最低格。

按攻击来源

• 合计：Section 4.2给出user侧100.0%（16/16），host侧75.0%（48/64），server侧32.5%（52/160）。按域合计，浏览器智能体52.6%（51/97），金融智能体45.5%（65/143）。host侧两基线均为0.0%。
• 作者解读：作者认为user侧的命令或敏感资源访问写在声明参数里；host侧检出集中在造成声明与实际不一致的Tool Call Hook。server侧许多攻击仍调用合法工具、参数语法有效，只改选择、参数、偏好或返回值，痕迹接近正常行为。
• 域差异：作者认为浏览器server侧有可疑URL、被遮蔽的导航工具和重复导航等信号；金融侧许多攻击改ticker、偏好或返回数值，但保持合法Yahoo Finance调用的预期结构。

误报与审计延迟

• FPR：Table 2中MTGuard为3.5%、1.8%、6.5%（浏览器，依次DS-V4-Flash、DS-V4-Pro、GPT-5.6 Luna）和3.3%、1.7%、5.2%（金融，同序）。作者给出非加权平均3.7%，对照TCG 0.3%、TRI 0.4%；并称浏览器平均3.9%、金融平均3.4%。作者认为浏览器轨迹更长、更杂，良性重复导航和跨站跳转可能被当成重放或偏离任务。作者把总体FPR联系到执行后核验的allow-by-default：与声明一致则默认允许。论文未给出各组安全调用的分母。
• 延迟：正文配合Figure 2：执行前平均5.93秒（浏览器）和5.68秒（金融），执行后6.74秒和6.40秒。作者称两阶段都调用时每工具调用约增加12.39秒。测量只含LLM审计，作者称未计入确定性规则、工具执行和沙箱或eBPF开销。摘要另称各设置平均额外延迟约10秒；论文未说明二者如何对应。作者认为执行后更慢，是因为提示词多了结果、行为树和DNS事件，并认为延迟有界，对安全敏感应用可能可以接受。

阶段消融

• 设置：PRA只留执行前审计；PRV留行为监控和执行后核验（Table 3）。作者给出总体DR：PRA 25.0%，PRV 31.7%，完整系统48.3%，且完整系统在六个配置的总体DR上都高于两个变体。
• 互补：作者报告PRA检出全部user侧不安全调用，host侧为0.0%。PRV的host侧为75.0%，user侧为6.3%。server侧完整系统32.5%，PRA 27.5%，PRV 16.9%。不是每个攻击来源格子都严格高于变体：浏览器server侧完整系统与PRA相同，host侧完整系统与PRV相同。
• 作者解读：作者认为两阶段对应不同失败模式，只用其一并不理想。

其他消融与分析

• 无防御ASR（附录B Table 4，按案例计）：host侧87.2%（68/78），server侧38.2%（71/186），user侧33.3%（11/33）。
• GPT-5.6 Luna的user侧ASR：浏览器20.0%，金融16.7%；作者认为它更常拒绝把恶意用户指令变成不安全调用。
• 每个攻击来源至少在部分设置中诱导出不安全调用；未成功案例不进入DR分母。
• TRI在Table 1全部格子为0.0%；user侧TCG与MTGuard同为100.0%。
• 论文没有其他参数扫描。执行后拒绝不能撤销已发生副作用；本次DR又是不阻断的反事实判定。

Limitations and Future Directions Noted by the Authors

• Interface Scope (Section 5.1): The authors state that the current prototype and evaluation target only locally deployed MCP tools. Conceptually, it can be mapped to function-calling APIs, LangChain tools, local functions, shell, and REST wrappers, but requires clear interception boundaries and control over the execution environment; remote execution or platforms lacking compatible sandboxes and system-level tracing may require provider-side instrumentation.
• Runtime Visibility (Section 5.1): Detection is constrained by the signals visible to the monitor. Currently, process, file, and network events are collected, including DNS-related metadata, but network payloads or application-level data flows are not inspected. The authors believe this may miss malicious behavior hidden in encrypted traffic, in-memory computation, or unobserved external services.
• No Rollback (Section 5.1): Post-execution verification only detects unsafe behavior after the tool has executed. Unsafe results can be suppressed, but system-level side effects that have already occurred cannot be automatically undone.
• Future Directions (Section 5.1): The authors list richer data-flow signals, payload-aware network inspection, selective online termination, and transactional execution or rollback.

Experimental Coverage

• The evaluation uses MCP-SafetyBench's browser automation and financial analysis, plus Tool Call Hook, totaling 99 attack cases, three backend models, and three source types: server/host/user (Section 4.1).
• Text audit is fixed to DeepSeek-V4-Pro; baselines are Agent-Aegis's TCG and TRI, replayed on the same tool-call traces (Sections 4.1–4.2).
• DR and FPR are computed per tool call, with labels from the case's built-in execution-based evaluator; refusal does not block execution (Section 4.1). The paper does not report the number of repetitions, nor the task completion rate after actual blocking.
• Runtime evidence includes process, file, network, and DNS responses within Docker; file events record file names rather than absolute paths (Section 3.3). The paper does not report the sampling settings of the audit LLM, nor the denominator of safe calls for FPR in Table 2.
• The ablation only compares PRA and PRV (Table 3). The case-level ASR without defense is in Appendix B, Table 4.

MTGuard is a hybrid analysis defense protecting LLM agents' MCP tool calls, deployed as an independent guard agent.

• Problem: Call declarations, metadata, and return text can be disconnected from actual system behavior; whether the same file or network operation is harmful depends on the task and tool declaration. The authors are particularly concerned about tool execution hijacking.
• Approach: Before dispatch, code rules and LLM audit parameters are used, and free-text descriptions that could be poisoned are discarded; during execution, eBPF in Docker records processes, files, networks, and DNS, aggregated into a tool behavior tree rooted at that call; after completion, consistency verification between declarations and observations is performed. No decisions are made during monitoring. Refusals occur before dispatch or by withholding results after completion; post-completion refusals do not roll back side effects.
• Main Results: On 99 attack cases, two domains, DeepSeek-V4-Flash, DeepSeek-V4-Pro, and GPT-5.6 Luna, MTGuard's overall DR is 48.3% (116/240), TCG is 8.3% (20 detections), and TRI is 0.0% (Table 1, Section 4.2). User-side is 100.0% (16/16), and TCG is also 100.0%; host-side is 75.0% (48/64), with both baselines at 0.0%; server-side is 32.5% (52/160), with DS-V4-Pro on browser at only 12.5% (2/16).
• Cost and Ablation: The non-weighted average FPR across six configurations is 3.7% (Table 2). The authors state that the two-stage LLM audit adds approximately 12.39 seconds per call, while the abstract also mentions approximately 10 seconds. The overall DR for PRA and PRV is 25.0% and 31.7%; PRA's host-side is 0.0%, and PRV's user-side is 6.3%.
• Authors' Conclusion: The authors state that joint analysis can cover different failure modes when only messages or only execution traces are considered, and believe that false positives and audit latency may be acceptable for security-sensitive applications. Section 5.1 also states that evidence is limited to local MCP tools, the monitor cannot see payloads and memory behavior, and cannot undo system side effects that have already occurred.