MCP工具调用安全：Agent工具面即攻击面

当Agent成为调用者，安全边界在哪里

MCP（Model Context Protocol）让AI Agent能够调用外部工具——读取文件、查询数据库、调用API。这正是它的价值所在，也是它最容易被忽视的风险所在。

大多数团队在部署Agent时，关注的是模型能力、工具覆盖度和响应质量，却鲜有人认真回答一个问题：谁来决定Agent调用哪个工具、用什么参数？

答案是Agent自己。它基于从各种来源拼装出的上下文——用户输入、检索到的文档、此前的对话轮次——来决定工具调用策略。而这些上下文来源，很多并不在你的控制范围内。

MCP（Model Context Protocol）是 Anthropic 于 2024 年底开源的协议标准，旨在为 LLM 应用与外部数据源、工具之间提供统一的连接方式，常被类比为「AI 世界的 USB-C 接口」。在 MCP 出现之前，每个 AI 应用要接入外部工具，往往需要自行编写适配代码，工具复用性差、生态割裂。MCP 通过定义标准化的服务器（Server）与客户端（Client）交互规范，让工具提供方只需实现一次 MCP Server，任何支持该协议的 Agent 都能直接调用。

这一设计极大降低了 Agent 的能力扩展成本，但也意味着 Agent 在运行时会动态获取并调用大量本不属于自身代码库的工具。一旦某个 MCP Server 暴露的工具具备写操作或高权限能力，Agent 被诱导滥用的后果将被放大。理解 MCP 的「协议中立性」——它只负责连接，不负责鉴权与审计——是理解本文安全命题的前提。

一个工具就是一个带模型的API端点

假设你的MCP服务器暴露了一个名为 execute_query 的工具，允许模型传入任意SQL语句。从安全视角看，这不是一个「工具集成」，而是一个以LLM为中间人的SQL注入漏洞。

传统的注入防御思路很清晰：将不可信输入隔离在查询之外。但在Agent场景下，不可信输入正是模型读取的上下文，而查询语句恰恰由模型生成。防火墙规则和表单验证器在这条路径上无处安放。

这意味着，攻击者不需要直接接触你的数据库。他只需要在Agent能读到的某段内容中嵌入精心构造的指令，就可能诱导Agent生成恶意查询。这是一种全新形态的注入攻击，传统安全工具无法覆盖。

间接提示注入（Indirect Prompt Injection）是相对于直接注入而言的：直接注入由用户在当前对话中直接输入恶意指令；间接注入则把恶意指令藏在 Agent 会读取的外部内容里，例如网页、PDF、数据库记录、代码注释、甚至工具返回结果。当 Agent 为了完成任务而检索这些内容时，恶意指令会作为上下文的一部分进入模型的决策过程，模型可能将其误认为合法指令并执行。

这种攻击的危险性在于攻击者与受害者之间不存在直接交互通道，攻击者只需在某个公开网页或共享文档中埋入指令，等待被检索即可。传统的输入过滤、WAF 等机制通常只扫描用户输入，对间接注入几乎无能为力。因此，Agent 场景下的注入防御必须覆盖「所有进入模型上下文的数据源」，而不仅是用户输入框。

判断Agent是否安全的唯一标准

判断一个Agent的工具调用是否安全，只需回答一个问题：

模型能否被用户、检索内容或对话历史所影响，以你未预期的方式调用工具？

如果答案是「能」——对大多数Agent而言，答案就是「能」——那么该工具的权限管理，就需要按照公开API端点的标准来审视。假设不受信任的人可以触达它，因为实际上他们确实可以。

这个判断框架的实用价值在于：它把Agent安全从「AI对齐」的抽象讨论，拉回到「API权限」的工程实践。你不需要解决对齐问题才能保护工具调用，你只需要像保护API那样保护它。

大多数Agent部署缺失的三道防线

在实际审视的大多数Agent部署中，以下三项控制措施普遍缺位：

按工具的授权范围限定

Agent只应获得完成当前任务所需的工具权限，而非对所有已注册工具的全面访问。一个摘要生成工具不需要shell访问权限。但在实际部署中，团队往往为了方便调试，直接给Agent开通了所有工具——这在生产环境中是一个严重的权限放大问题。

最小权限原则（Principle of Least Privilege）是安全工程的基石之一，最早由 Saltzer 和 Schroeder 在 1975 年提出，要求任何主体只能获得完成其当前任务所必需的最小权限集，且权限应在任务结束后及时回收。在传统系统中，这一原则通常通过角色、作用域（scope）和令牌（token）来实现。

在 Agent 场景下，最小权限的落实更为棘手，因为 Agent 的工具需求是动态的、由模型自行判断的。可行的做法包括：为每个工具定义独立的作用域并绑定到具体任务；在会话级别而非 Agent 级别授予工具权限；对高危工具（如 shell、写文件、执行 SQL）引入人工确认或二次鉴权；以及设置工具调用频率与并发上限，防止一次提示注入触发大规模操作。这些措施共同构成「纵深防御」的第一层。

执行前的输入校验

在工具运行之前，就应检查传入参数是否符合工具应接受的范围。运行之后再检查，那不是防御，那是事件响应。这里的难点在于，Agent传入的参数是动态生成的自然语言转结构化数据，需要专门设计校验层。

全量工具调用审计日志

记录每次工具调用、传入参数以及产生该调用的完整上下文。缺少上下文，日志只能回答「发生了什么」，而无法回答「为什么发生」——后者恰恰是所有安全审查真正关心的问题。没有上下文的审计日志，在事后取证中几乎无法发挥作用。

老问题，新调用者

这三项控制本身并不新鲜。它们正是你已经在API上实施的安全措施。Agent带来的变化只有一个：调用者变了。

过去调用API的是经过认证的用户或服务，现在调用API的是一个可能被对抗性输入操纵的模型。API的防护措施仍然适用，只是需要在模型与API之间增加一层适配——确保模型的输出在触达真实API之前，经过与人类用户同等严格的校验。

你的Agent工具面就是你的攻击面。值得用对待攻击面的方式来对待它。