MCP 服务器安全风险：当 AI 智能体拥有你的全部权限

一位开发者在使用 Claude 编码智能体时，顺手检查了其所调用的 MCP（Model Context Protocol）shell 服务器的进程树与 UID，结果显示：该 MCP 服务器以当前用户身份运行——从操作系统内核的视角看，它就是用户本人，没有任何隔离、没有审计、没有能力限制。这一发现引出了关于 AI 智能体执行环境安全的一系列警示。

一、MCP 服务器的权限边界即用户自身

在 POSIX 系统下，以用户 UID 运行的进程天然拥有该用户的所有能力。具体到 MCP 服务器场景，意味着它可以：

读取、修改、删除该用户拥有的任意文件
取走 ~~/.ssh 中的 SSH 密钥、~~/.aws/credentials 中的云凭证、API Token、GPG 密钥环
向 git 远程仓库推送代码
执行系统中已有的任意二进制，或通过 pip、npm、cargo 等渠道安装新程序
向任意可达的网络地址发起请求
利用本地凭据已认证的所有服务进行横向移动

以上操作不需要 sudo 密码，也不会触发任何系统提示——全是用户进程的「正常」行为。作者特别指出，主流信任模型是「我只运行可信的 MCP 服务器」，但信任并非静态，且攻击面不止服务器二进制本身。

二、被低估的向量：提示注入

作者认为，相对于 MCP 服务器本身是否可信，更危险的是提示注入（prompt injection）。模型在注意力层面并没有「我正在读取的内容」与「我应当遵循的指令」之间的硬隔离——外部数据和系统指令共用同一个上下文窗口。

文中给出的典型场景是：用户让 Claude 总结一封邮件中的文档，文档中嵌入隐藏指令（例如 HTML 注释里的 ）。模型读取后，依据其配置与上下文结构，可能直接执行该指令。作者强调，此类攻击已在公开场合针对已发布产品反复演示，并非假设。

当 MCP 服务器未沙箱化时，一次成功的提示注入造成的爆炸半径就是用户整个账号；再叠加横向移动与权限提升，则延伸到整个系统、网络、设备、家庭自动化、财务账户。沙箱化的 MCP 服务器则把最坏情况收敛到容器内被显式允许的操作范围，成为一个可控的问题。

三、作者的实践：mcp-box 沙箱

为把隔离变成默认而非临时加固，作者开发了 mcp-box，核心做法是用容器承载 MCP 服务器：

只读根文件系统
全部 Linux capabilities 丢弃
默认关闭网络，需显式启用才放行
主机 UID 映射，避免容器内文件归属混乱

运行 id 后显示的 UID 仍是用户本人，但所有动作被约束在容器边界之内。这种把权限边界从「我相信这个 MCP 服务器」切换到「我只暴露我选择暴露的能力」的范式，被作者视为现阶段最务实的缓解手段。

四、对使用者的建议

在把任何 MCP 服务器接入 AI 智能体之前，明确它将以何种身份、具备何种能力运行
把承载敏感凭据的工作环境与智能体执行环境做系统级隔离
假设 AI 在处理外部内容时，可能把内容中的指令当作可执行指令
关注操作系统级权限边界，而不是仅依赖模型对齐
把沙箱当作 MCP 部署的默认选项，而非事后补救

随着 AI 智能体逐步接入文件系统、终端、网络与浏览器，传统「用户—进程」模型下的信任假设正在被重写。MCP 这类协议把模型能力投射到本机资源上，速度远快于对应的安全工具与流程迭代，这正是作者希望提醒同行的核心问题。