Agent 越能干越危险：MCP、代码执行、密钥和沙箱怎么防翻车

AI Agent 最大的价值，是它不只会回答问题，还能调用工具、读写文件、执行命令、访问数据库、操作浏览器，甚至修改生产系统。

这也是它最大的风险。

一个只能聊天的模型，最多给出错误建议。一个能执行命令的 Agent，可能真的删文件、泄露密钥、提交错误代码、调用危险接口，或者把内部数据发送到不该去的地方。

所以 Agent 安全的核心不是“模型会不会出错”，而是：它出错时，最多能造成多大损失。

第一条边界：权限最小化

很多团队接入 Agent 的第一步，就是给它一个很大的权限：整个代码库、完整终端、所有环境变量、浏览器登录态、数据库连接。

这很方便，也很危险。

正确做法是把权限拆小：

• 只给需要的目录读写权限。
• 默认不暴露生产密钥。
• 危险命令需要确认。
• 数据库优先只读。
• 外部网络访问要有白名单。
• 生产环境操作必须人工审批。

Agent 不是人，它不会天然理解“这个命令虽然能跑但不该跑”。权限边界必须由系统保证，不能只靠 prompt 约束。

第二条边界：MCP 工具不是越多越好

MCP 让模型连接外部工具变得更标准，这是好事。但每接一个 MCP server，本质上就是给 Agent 多开一扇门。

常见风险包括：

• 工具描述被误解，模型调用了不该调用的能力。
• MCP server 读取了过多本地文件。
• 工具返回的数据里混入 prompt injection。
• 连接内部系统后，Agent 误操作真实业务数据。
• 第三方 MCP server 自身不可信。

所以 MCP 工具要分级管理：

• 低风险：只读文档、搜索、格式转换。
• 中风险：读内部数据、查询数据库、访问代码仓库。
• 高风险：写文件、发消息、提交 PR、改数据库、部署系统。

高风险工具不要默认开放，至少要有确认、日志和回滚方案。

第三条边界：密钥永远不要随便进上下文

Agent 很容易接触到密钥：环境变量、配置文件、CI 日志、.env、云平台 token、Webhook 地址、数据库密码。

一旦密钥进入模型上下文，就可能被记录、转发、写进文件、出现在日志里，或者在后续任务中被误用。

建议做几件事：

• .env、私钥、token 文件默认加入 Agent 忽略列表。
• 执行命令时过滤敏感环境变量。
• 日志输出做 secret masking。
• 只给短期、低权限 token。
• 对外部工具调用做数据脱敏。
• 定期轮换 Agent 使用过的凭证。

不要用一句“不要泄露密钥”的 prompt 当安全方案。prompt 是提醒，不是隔离。

第四条边界：代码执行必须进沙箱

Coding Agent 必然要执行命令：安装依赖、跑测试、生成文件、启动服务。问题是，命令执行是高危能力。

风险可能来自三个地方：

• 模型自己生成了危险命令。
• 项目脚本里本来就有危险行为。
• 依赖安装时触发供应链风险。

因此，团队使用 coding agent 时，最好把执行放进沙箱：

• 用临时工作区，而不是直接操作主目录。
• 用容器或隔离用户执行命令。
• 限制网络访问和文件系统范围。
• 对包安装、部署、删除命令加确认。
• 每次任务结束后清理环境。

沙箱的目标不是让 Agent 永远不犯错，而是让它犯错时影响范围可控。

第五条边界：所有关键操作都要可审计

Agent 安全还有一个经常被忽略的问题：出了事之后，你能不能复盘？

至少要记录：

• 用户给了什么任务。
• Agent 读取了哪些文件。
• 调用了哪些工具。
• 执行了哪些命令。
• 修改了哪些文件。
• 哪些操作经过人工确认。
• 最终产物和 diff 是什么。

没有审计日志，Agent 就像一个动作很快但不留痕的外包。短期看效率高，长期看风险大。

一个实用的 Agent 安全分级

可以把 Agent 使用分成四级：

级别	能力	安全要求
L1	只读问答	数据脱敏、引用来源
L2	读代码/读文档	限制目录、禁止密钥
L3	写文件/跑测试	沙箱、diff review、命令确认
L4	改数据库/部署/发消息	人工审批、审计日志、回滚方案

大多数团队可以从 L2/L3 开始，不要一上来就把 L4 能力交出去。

对个人开发者的建议

个人使用 Agent，也不要太随意。

至少做这些：

• 不要让 Agent 读取包含密钥的目录。
• 重要仓库先 commit，再让 Agent 修改。
• 看 diff，再执行危险命令。
• 不要把生产数据库连接给 Agent。
• 不要让未知 MCP server 访问全盘文件。
• 给常用 Agent 单独建工作目录。

个人电脑里的 SSH key、云平台 token、浏览器登录态，价值可能比你想象得高。

对团队的建议

团队要把 Agent 当成一种新型自动化执行者，而不是普通聊天工具。

建议建立这些制度：

• Agent 权限矩阵。
• MCP server 白名单。
• 密钥和敏感文件策略。
• 沙箱执行环境。
• 操作审计和日志留存。
• PR/diff review 流程。
• Agent 输出的测试和评测基线。

如果团队已经允许 Agent 写代码、跑命令、提交 PR，那么它就已经进入工程治理范围了。

结论

Agent 越强，越不能只靠信任。

真正安全的 Agent 系统，不是模型永远不会犯错，而是系统提前假设它会犯错，并把损失限制在可接受范围内。

一句话总结：把 Agent 当成一个高效率但需要隔离的执行者，而不是一个永远可靠的同事。

当你开始接入 MCP、开放代码执行、暴露内部数据和密钥时，安全边界就不是可选项，而是 Agent 能否进入生产环境的前提。

参考来源

• Model Context Protocol：https://modelcontextprotocol.io/
• Anthropic Agent Skills：https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
• OpenAI Agents SDK：https://openai.github.io/openai-agents-python/
• OWASP Top 10 for LLM Applications：https://owasp.org/www-project-top-10-for-large-language-model-applications/
• GitHub Secret Scanning：https://docs.github.com/en/code-security/secret-scanning