如果您通过模型上下文协议（MCP）运行人工智能代理（例如克劳德代码、光标或任何 MCP 客户端），您的工具调用现在会流经 MCP 服务器：文件系统服务器、数据库服务器、命令行解释器。这种标准化非常棒。但这也意味着，单次幻觉产生的或被提示注入的工具调用可能造成真实且不可逆的损害，而模型在发出调用之前，无法区分破坏性调用与安全调用。
因此，人们会问：这个 MCP 服务器安全吗？
更好的问题应该是这样的。您的代理最终总会向 MCP 服务器发送某些具有破坏性的内容。问题不仅在于您是否拦截了它，更在于拦截后运行过程能否继续存活。
一行代码即可拦截。无需编写代码，无需密钥。
使用 agentx-mcp 包装任何 MCP 服务器。它是一个小型的标准输入输出代理：它会生成真实的服务器，原样中继 MCP 协议，并在执行前筛查每一个 tools/call（工具调用）。在您的 mcp.json 文件中只需添加一行：
{
"mcpServers": {
"database": {
"command": "agentx-mcp",
"args": ["npx", "-y", "your-real-mcp-server", "..."]
}
}
}
pip install agentx-security-sdk # 这将提供 agentx-mcp 命令
现在，代理发出的每个工具调用都会先经过确定性层的检查。DROP TABLE（删除表）、未限定范围的 DELETE（删除）、秘密存储读取、针对 169.254.169.254 的服务器端请求伪造攻击、rm -rf（强制递归删除）：所有这些在到达服务器之前都会被拦截。无需应用程序编程接口密钥，没有任何数据离开您的机器，拦截过程中不涉及处于关键路径的大型语言模型。它适用于任何支持 MCP 的技术栈，因为它筛查的是协议，而非您的代码。
这部分内容您可以在两分钟内自行验证，无需信任我。
导致运行中断的拦截依然意味着代理失效
大多数关于“是否安全”的回答到此为止：危险调用被拦截，工具返回错误，您的代理放弃任务。在自主运行过程中出现硬性的 403 禁止访问错误，本身就是一种失败。任务未能完成。您只是用一种失败结果换取了另一种。
因此，agentx-mcp 会指导代理，而非直接终止它
当防护盾拦截一个 tools/call（工具调用）时，agentx-mcp 不会返回死板的错误。它会返回一个指导性的工具错误，指出不安全之处并指引安全的路径。您的代理在下一次轮询时会读取该信息，进行修正，并尝试安全的版本。运行过程得以继续。
以下是在真实 MCP 服务器上端到端的循环过程：
- 代理的任务是“报告用户数量”。其查询中隐藏着一个注入攻击：
SELECT name FROM users; DROP TABLE users;（从用户表中选择姓名；删除用户表；） -
a免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
