AI Agent 安全实战：从 MCP 漏洞到权限沙箱，生产环境必须知道的事

Sun, 02 Aug 2026 08:30:00 +0800

上一篇我们拆了 MCP 生态的 5 条攻击路径——30+ CVE、20 万台服务器中招、1.5 亿次下载处于风险。数据摆完，一个现实问题浮出来：知道了攻击者怎么打进来，接下来怎么防？

这篇文章不重复列漏洞。我要讲的是生产环境的安全工程——权限怎么设计、沙箱怎么选、审批流怎么建、供应链怎么审。每一条都有对应的技术方案和真实案例，看完直接能落地。

OWASP Agentic Top 10：AI Agent 的专属安全标准

2025 年 12 月，OWASP 正式发布了 Agentic AI Top 10——这是继 LLM Top 10 之后，专门针对自主 AI Agent 的安全风险标准。两套标准互补：LLM Top 10 关注模型层面的漏洞（prompt injection、数据泄露），Agentic Top 10 关注 Agent 作为「自主行动体」带来的结构性风险。

核心风险条目：

编号	风险	一句话解释
Ag1	Agentic 机制滥用	Agent 被诱导执行非预期动作
Ag2	工具链安全	调用的工具本身有漏洞或恶意
Ag3	多 Agent 信任链	Agent 间传递的信息被污染
Ag4	上下文投毒	恶意内容注入 Agent 的上下文窗口
Ag5	权限提升	Agent 突破任务边界获取更高权限
Ag6	记忆/状态污染	持久化记忆被投毒，影响后续决策
Ag7	工作流劫持	攻击者篡改 Agent 的执行流程
Ag8	身份冒用	Agent 假冒其他身份执行操作
Ag9	资源耗尽	无限循环、Token 滥用导致成本失控
Ag10	审计缺失	没有日志，出事无法追溯

这不是学术分类——每一条都对应我在 #32 中拆解过的攻击路径。区别在于：#32 从攻击者视角讲「怎么打进来」，现在切换到防御者视角讲「怎么建防线」。

权限最小化：Agent 不该用你的钥匙开门

权限设计是第一道防线，也是最容易做错的一环。很多团队的 Agent 直接复用开发者的个人凭证——GitHub token、AWS key、数据库密码。一旦 Agent 被注入恶意指令，攻击者等于拿到了你的全套权限。

三个核心原则

原则一：Agent 身份独立化。 Agent 需要自己的身份，不是复用人的凭证。微软在 2026 年 7 月发布的《Least Privilege for AI Agents》白皮书中明确建议：每个 Agent 分配独立的服务账号，权限范围严格限定在任务所需之内。

原则二：Task-scoped RBAC。 传统 RBAC 是按角色分配权限——「开发者」角色拥有所有开发工具的访问权。Agent 安全需要的是按任务分配权限：一个负责「读代码并生成文档」的 Agent，不应该有写入数据库的权限。

原则三：Tool binding 而非 prompt 约束。 很多人在 system prompt 里写「不要删除文件」「不要访问外部网络」——这不叫安全，叫「请攻击者用 prompt injection 覆盖你的规则」。权限控制必须在工具层强制执行（runtime checks），不是在 prompt 里写规矩。

Amazon 的真实教训

Amazon 内部在多次成本高昂的生产事故后，强制推行了「AI 辅助代码变更需显式审批」的政策。任何由 AI Agent 生成或修改的代码变更，必须经过人工审批才能合入主分支。这不是不信任 AI，而是承认：自动化操作的错误率虽然低，但一旦出错，影响面比人工操作大得多。

落地建议：30 天内盘点你的 Agent 身份，移除宽泛角色，引入任务级 RBAC。优先审计那些拥有「admin」或「write-all」权限的 Agent 服务账号。

沙箱隔离选型：五种技术，怎么选

Agent 有了独立身份，下一步是限制它能接触到的资源。沙箱隔离的核心思想：即使 Agent 被注入恶意指令，它也突破不了运行时的边界。

五种主流技术对比

技术	代表工具	隔离强度	性能开销	适用场景
Bubblewrap (namespace)	Codex CLI	中	极低	文件系统隔离，开发环境
gVisor (用户态内核)	Google Cloud Run	高	中	容器级隔离，云端部署
MicroVM (Firecracker)	Docker Sandbox, Northflank	最高	高 (128MB+/VM)	企业级隔离，多租户
Container (Docker)	Docker Sandboxes	中-高	低	通用场景
WASM	Cosmonic	中	极低	插件级隔离

Codex vs Claude Code：两种截然不同的策略

Codex CLI 默认强制启用 Bubblewrap 沙箱，所有文件操作和 shell 命令都在 namespace 隔离中执行。Claude Code 则走可配置路线——开发者可以调整沙箱的严格程度，甚至完全关闭。

两种策略各有道理：Codex 适合「安全优先，体验次之」的场景；Claude Code 适合「开发者清楚自己在做什么，需要灵活度」的场景。我的建议是：生产环境用 Codex 的强制模式，开发环境可以用 Claude Code 的可配置模式。

Docker Sandbox 的 microVM 升级

2026 年 7 月，Docker 发布了基于 microVM 的沙箱隔离方案。传统容器共享宿主机内核，逃逸漏洞虽然罕见但存在（如 CVE-2024-21626）。microVM 在容器和宿主机之间加了一层虚拟化——每个 Agent 运行在独立的微虚拟机中，即使逃逸容器，也撞上虚拟化层。

性能代价？每个 microVM 最少需要 128MB 内存。对于跑几十个 Agent 的场景，内存开销不小。但对于高安全需求的生产环境，这是目前最可靠的隔离方案。

场景推荐

开发/测试：Bubblewrap 或 Container，够用就行
内部工具/CI：Container + 网络隔离
面向客户的 Agent：gVisor 或 MicroVM
多租户 SaaS：MicroVM，没商量

敏感操作审批流：哪些事不能让 Agent 自己决定

权限再小、沙箱再硬，总有些操作必须人工把关。关键问题是：怎么定义「哪些操作必须审批」？

必须人工审批的操作

操作类型	为什么必须审批	典型后果
删除资源	误删无法自动恢复	数据丢失
支付/转账	资金不可逆	直接经济损失
生产部署	影响线上用户	服务中断
凭证变更	可能导致权限失控	安全事件
外部 API 调用	无法撤回	数据泄露

Approval Gate 实现方案

最简单的实现：在 Agent 的 tool 定义中，对敏感操作标记 requires_approval: true。当 Agent 尝试调用该工具时，框架暂停执行，发送审批请求到 Slack/邮件/IM，等待人工确认后继续。

1
2
3
4
5


Agent 调用 "delete_resource(id=xxx)"
 → 框架检测到 requires_approval
 → 暂停执行，发送审批通知
 → 人工审核 → 批准/拒绝
 → 批准：继续执行 → 拒绝：终止并记录

读写分离原则

一个被低估的安全设计：把读操作和写操作拆成不同的 Agent。 读 Agent 只有查询权限，写 Agent 有修改权限但必须通过审批流。这样即使读 Agent 被注入恶意指令，它也压根没有写入的能力——不是「不让它写」，而是「它物理上不能写」。

供应链安全审计：MCP Server 不是随便装的

MCP 生态的供应链攻击已经不是假设性威胁。在 #32 中我们拆解过 npm typosquatting、后门代码、恶意 MCP Server 等真实案例。这里讲怎么防。

安装前必做检查

装一个 MCP Server 之前，至少检查这几项：

检查项	怎么查	红线
来源	GitHub/GitLab 仓库地址	无仓库或个人小号
Star 数	低于 100 需警惕	低于 10 且刚发布
维护频率	最近 commit 时间	超过 6 个月无更新
依赖树	`npm audit` / `pip-audit`	有已知 CVE 未修
代码审查	快速扫一眼主入口文件	有混淆代码或可疑网络请求

运行时监控

安装检查只是第一道关。运行时监控更关键：

网络流量审计：MCP Server 启动后，用 netstat 或 ss 检查它连接了哪些外部地址
文件系统监控：用 inotifywait 或 auditd 监控它读写了哪些文件
进程行为：strace -f -e trace=network 追踪它的系统调用

Docker MCP 的供应链方案

Docker 推出的 MCP marketplace 对上架的 Server 做了三重检查：静态代码扫描、依赖树审计、运行时行为监控。虽然不能保证 100% 安全，但比直接从 npm 装一个未审核的包靠谱得多。

建议：生产环境只用经过审核的 MCP Server，开发环境可以用社区的但必须容器化隔离。

全链路审计追踪：出事能追溯

安全的最后一道防线是审计。如果 Agent 被注入恶意指令并执行了破坏性操作，你需要能回答三个问题：做了什么、什么时候做的、是谁触发的。

审计日志必须包含的字段

每一条 tool call 记录必须包含：

时间戳：精确到毫秒
Agent ID：哪个 Agent 执行的
Task ID：属于哪个任务
Tool 名称：调用了什么工具
输入参数：传了什么参数
执行结果：成功/失败/返回值
触发来源：用户手动触发还是 Agent 自动调用
审批状态：是否经过人工审批

异常行为检测

基于审计日志，可以设置告警规则：

单个 Agent 在短时间内调用大量写操作
Agent 访问了任务范围之外的工具
Agent 尝试读取凭证文件（.env、.ssh）
Agent 向外部 IP 发送大量数据
同一 Agent 在非工作时间执行操作

这些规则不需要复杂的 ML 模型——简单的阈值检测就能拦住 80% 的异常行为。

落地安全检查清单

最后附一个可直接执行的 checklist。按这个过一遍，你的 Agent 安全基线就有了：

权限层

Agent 使用独立服务账号，不复用个人凭证
权限按任务分配（Task-scoped），不是按角色
敏感工具标记 requires_approval
读写 Agent 分离

沙箱层

Agent 在隔离环境中运行（Container/MicroVM/gVisor）
网络访问白名单限制
文件系统只读挂载（除必要写入目录）
资源配额（CPU/内存/Token）设置上限

审批层

删除、支付、部署、凭证变更必须人工审批
审批流有超时机制（避免无限等待）
审批记录持久化存储

供应链层

MCP Server 安装前完成来源/Star/依赖检查
运行时网络流量和文件访问监控
生产环境只用审核过的 MCP Server

审计层

所有 tool call 有完整日志
异常行为告警规则已配置
日志保留至少 90 天
支持按 Agent/Task/时间范围查询

这篇文章的核心观点只有一句：Agent 的安全不是「写好 prompt」的问题，是「建好工程」的问题。 权限、沙箱、审批、供应链、审计——这五层防线少一层都不行。

如果你正在生产环境跑 AI Agent，建议先拿上面的 checklist 对照一遍。有具体问题欢迎评论区聊。

系列文章：

MCP 安全血案：5 条攻击路径、20 万台服务器中招

本文：Agent 安全实战（防御侧）

Codex CLI 上手：OpenAI 的沙箱安全编程方案

Sun, 12 Jul 2026 08:30:00 +0800

AI 编程 Agent 能执行任意命令，这意味着它也能删库、泄露密钥、安装后门。信任问题不解决，自主编程就是空谈。

OpenAI 的 Codex CLI 选择了一条不同的路：不靠"请你信任我"，而是用沙箱把 Agent 关进笼子里。97,000+ Star、Rust 重写、Apache-2.0 开源——这是目前安全设计最完善的终端编程 Agent。

为什么需要"安全编程"

AI 编程工具有个天然的取舍：给的自由越多，风险越大。

Agent 需要执行 shell 命令才能干活——装依赖、跑测试、提交代码。但 shell 命令是无限制的：rm -rf / 也是合法命令。你给 Agent 一个任务，它可能顺手执行了你没想到的操作。

已经出过事了。2026 年多个 AI 编程工具被曝出安全问题：沙箱逃逸、权限提升、未授权网络访问。企业用户不敢用，因为一次意外就可能影响生产环境。

Codex CLI 的答案是：默认不信任 Agent，用系统级隔离强制约束行为。

Codex CLI 是什么

项目	值
GitHub	github.com/openai/codex
Stars	97,204
语言	Rust（从 TypeScript 重写）
许可证	Apache-2.0
开发商	OpenAI
支持模型	GPT-5 系列、codex-1 专用模型

Codex CLI 是 OpenAI 开源的终端编程智能体。三种形态：CLI 终端、VS Code 插件、Codex Cloud 云端。核心特点是把安全沙箱做成了系统级能力，而不是靠 prompt 约束。

Rust 重写不只是为了性能。Rust 的内存安全特性让沙箱实现本身更难被绕过——没有 use-after-free、没有 buffer overflow，攻击面从语言层就被收窄了。

五层安全防线

这是 Codex CLI 的核心卖点，也是它与其他工具拉开差距的地方。

第一层：三级沙箱模式

1
2
3
4
5


read-only 只读，不能写文件、不能执行命令
 ↓ 降低约束
workspace-write 可写项目目录，可执行本地命令（默认）
 ↓ 降低约束
danger-full-access 无限制访问（需要显式声明 danger）

默认是 workspace-write——Agent 只能修改当前项目目录的文件，不能动系统文件、不能改其他项目。想突破这个边界？必须显式声明 danger-full-access，名字本身就提醒你这是危险操作。

第二层：审批控制

沙箱管"能做什么"，审批管"什么时候需要问人"：

策略	行为
`untrusted`	非信任命令都要问
`on-request`	沙箱内自由操作，越界时才问（推荐）
`never`	完全自动，不问任何人

最佳实践：--sandbox workspace-write --ask-for-approval on-request。Agent 在项目目录里自由干活，一旦要访问目录外的资源、使用网络、执行敏感命令，就停下来等你确认。

第三层：可写目录白名单

如果 Agent 需要写多个目录（比如同时改前端和后端），不用开 full-access，用 writable_roots 白名单：

1
2
3
4
5
6


# config.toml
[sandbox_workspace_write]
writable_roots = [
 "/home/user/frontend",
 "/home/user/backend"
]

精确控制哪些目录可写，其余一律只读。最小权限原则的工程实现。

第四层：平台原生隔离

Codex 不是用 Docker 容器做隔离，而是用操作系统原生的安全机制：

平台	隔离机制
macOS	Seatbelt 框架（系统级沙箱）
Linux	bubblewrap（用户命名空间隔离）
Windows	双用户架构（CodexSandboxOffline/Online）
WSL2	复用 Linux 的 bubblewrap 方案

Windows 的实现比较巧妙：创建两个本地用户，CodexSandboxOffline（防火墙阻断出站网络）和 CodexSandboxOnline（允许网络），密码随机生成后用 DPAPI 加密存储。Agent 运行在受限用户下，天然无法访问你的个人文件。

第五层：自动审核

设置 approvals_reviewer = "auto_review" 后，审批请求不是弹给你，而是交给另一个 AI Agent 审核。Agent 审 Agent——审核者有权拒绝越界操作，形成双重校验。

安装与上手

macOS / Linux

1

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Linux 需要先装 bubblewrap：

1
2
3
4
5


# Ubuntu/Debian
sudo apt install bubblewrap

# Fedora
sudo dnf install bubblewrap

Windows

1

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

认证

两种方式：

ChatGPT 账号：运行 codex 后选 “Sign in with ChatGPT”，Plus/Pro/Business 套餐包含 Codex 额度
API Key：设置 OPENAI_API_KEY 环境变量

AGENTS.md

在项目根目录放一个 AGENTS.md，告诉 Agent 项目上下文：

1
2
3
4
5
6
7


# 项目说明
这是一个 Next.js 15 项目，使用 TypeScript + Tailwind CSS。

# 规则
- 测试用 vitest，不要用 jest
- 提交信息用 conventional commits 格式
- 不要修改 .env 文件

Codex 启动时会自动读取这个文件，相当于给 Agent 一份项目手册。

实战演示

场景 1：安全模式下重构代码

1

codex --sandbox workspace-write --ask-for-approval on-request

在这个模式下，Agent 可以自由读写项目文件、运行测试。但当它尝试 npm install 一个新包（需要网络）时，会弹出审批提示。你确认后才继续。

场景 2：CI/CD 管道中的静默模式

1
2


codex exec --sandbox workspace-write --ask-for-approval never \
 "运行所有测试，如果有失败的修复它们，然后提交"

exec 是一次性执行模式，跑完自动退出。配合 --ask-for-approval never 适合自动化管道——但沙箱仍然生效，Agent 不能突破项目目录。

场景 3：/goal 自主执行

在交互模式下输入 /goal，Agent 进入自主循环：规划 → 执行 → 验证 → 继续，直到目标完成。沙箱和审批策略全程生效。

与 Claude Code、OpenCode 对比

维度	Codex CLI	Claude Code	OpenCode
开发商	OpenAI	Anthropic	社区
语言	Rust	TypeScript	Go
安全设计	五层沙箱 + 平台原生隔离	沙箱 + 权限控制	BYOK，无内置沙箱
沙箱机制	bubblewrap/Seatbelt/Windows Sandbox	类似但实现不同	无
审批控制	三级策略 + 自动审核	有	基础
可写目录白名单	`writable_roots`	有	无
模型	GPT-5 系列 + codex-1	Claude 4 系列	75+ 模型
MCP 支持	✅	✅	✅

安全设计维度，Codex CLI 领先一个身位。 它的沙箱不是应用层的权限检查，而是操作系统级的强制隔离——Agent 想逃逸，得先攻破 bubblewrap 或 Seatbelt。

Claude Code 也有沙箱，设计思路类似，但实现深度不同。OpenCode 走的是 BYOK（Bring Your Own Key）路线，安全完全交给用户自己负责。

谁该用 Codex CLI

首选场景：

企业/金融/医疗等安全敏感行业：沙箱隔离是刚需，不是锦上添花
OpenAI 生态用户：已经用 GPT-5 系列，Codex CLI 是最自然的编程 Agent 选择
团队协作：自动审核功能让多人共用 Agent 时有统一的安全策略
CI/CD 集成：静默模式 + 沙箱 = 安全的自动化编程

不太适合的场景：

需要频繁切换多个 LLM 模型的用户（Codex 主要服务 OpenAI 模型）
超长上下文任务（Claude 的长上下文更稳定）
预算敏感的纯 API 用户（Codex-1 专用模型按 token 计费）

结论

AI 编程 Agent 的竞争正在从"谁能写更好的代码"转向"谁更值得信任"。Codex CLI 的五层安全防线不是营销话术，而是工程落地：操作系统级沙箱、最小权限白名单、Agent 审 Agent 的自动审核。

沙箱不是限制，是 Agent 自主运行的前提。 你得先确定它不会越界，才敢放手。Codex CLI 目前是安全机制最完善的终端编程 Agent。

沙箱 on Kalend's Blog