AI Agent 安全系列：1. AI Agent 结构拆解

Sat, 10 Oct 2026 00:00:00 +0000

2025 年以来，主流 coding agent 的漏洞通报进入高发期，Claude Code、Codex、Cursor、Gemini CLI、GitHub Copilot 相继出现可由恶意仓库远程触发的严重漏洞。Claude Code 的 CVE-2025-59536，恶意仓库携带的 hooks 配置先于信任对话框执行[1]；Codex CLI 的 CVE-2025-61260，项目本地的 MCP 配置被自动加载，克隆一个仓库就交出执行权与 GitHub token[2]；Cursor 的 DuneSlide（CVE-2026-50548/49），沙箱写入白名单按模型填写的参数构建，注入内容可以让白名单指向沙箱执行器本身[4]。

Gemini CLI 的 CVE-2026-12537，工作区信任判断与工具白名单被绕过，最终落到容器启动器的命令注入[5]；GitHub Copilot 的 CVE-2025-53773，恶意仓库把 autoApprove 写进设置，agent 直接进入全自动模式[6]。2026 年 9 月，Codex 再披露 Heapjack 与 Overpatch 两个无 CVE 编号的沙箱逃逸漏洞，共同根因是沙箱的强制机制与被它限制的代码处在同一信任域[3]。

这些漏洞的直接根因各不相同，覆盖执行时序、配置自动加载、沙箱构建方式、信任判断与白名单解析，但失效位置集中在少数几个部件上：配置加载、权限判定、沙箱边界与框架自身代码。失效位置如此集中并非偶然，它与 agent 的内部结构直接相关。要回答“为什么是这几个位置”，需要先把 agent 拆开，弄清它由哪些部件组成、哪些输入能够进入、中间有几道关卡。

这是 AI Agent 安全系列的第一篇。系列的分析路径是：从内部结构推导攻击面，再从每个攻击面推导攻击路径，每一步用公开的 CVE 与 writeup 印证。

与传统软件的本质差别：输入参与决策

传统软件同样要处理不可信输入：浏览器解析网页，邮件客户端解析邮件，攻击者控制的内容每天都在进入系统。但传统软件的数据与程序是分离的，输入是数据，不参与决定程序下一步做什么。浏览器拿到一段 HTML，按照写定的渲染逻辑绘制页面；攻击者若想利用，必须先找到解析器或内存管理的缺陷，把数据变成控制流，这是漏洞挖掘的传统路径，门槛不低。

agent 改变了这个前提，网页内容、issue 评论、依赖包里的注释、MCP server 返回的结果，进入 agent 之后都直接参与决定下一步调用哪个工具、传递什么参数，模型把读进的一段文字转成一次工具调用，输入由此从数据变成了决策依据本身。

两种模型的差别如下图：

输入参与决策是第一条事实，权限是第二条。coding agent 通常持有开发者本人的完整权限，从读写文件、执行命令到使用其凭证，这种权限是产品前提而非实现上的省事：agent 要执行业务，就必须持有相应权限。两条事实合在一起，构成 agent 安全的核心问题：不可信内容能够影响决策，决策的执行又携带完整权限，中间的防线是什么、能否有效拦截。输入与执行之间的这些防线，正是 Agent 安全研究的对象。

Attack-Surface on iamelli0t's blog

AI Agent 安全系列：1. AI Agent 结构拆解

与传统软件的本质差别：输入参与决策