2025 年 12 月，OWASP 发布 2026 版 Agentic Applications Top 10[1]，列出智能体应用的十类主要威胁，下面的推导以它为参照。 第 1 篇把 agent 运行时拆成六层与两个部件，并留下两条结构性事实：结构性事实 1 是所有外部内容在组装时汇成一条没有来源标记的平坦 token 流；结构性事实 2 是判定检查点只覆盖“模型 → 动作”这一段，内容进入与配置加载都不经过它。沿着这张结构图推导，得到的攻击面与威胁清单不同：它的意义在于可检验，任何一个新漏洞、新技术出现，都能定位它落在哪个攻击面上；定位不上，则暴露的是结构图的缺口，两种结果都推进认识。 推导按三个问题展开：agent 的行为由哪些状态决定，执行由哪些关卡拦截；这些状态与关卡推出哪几个攻击面，各落在架构图的什么位置；一个攻击面要变成一次实际攻击，中间还差什么。 OWASP 2026 版 Agentic Applications Top 10 图源：OWASP Top 10 for Agentic Applications（2026）[1]。十类如下： 目标劫持（ASI01）：利用模型无法可靠区分指令与内容的固有弱点，操纵 agent 的目标、任务选择与决策路径，影响覆盖后续多步行为而非单次回答； 工具滥用与利用（ASI02）：agent 在授权范围内以不安全或非预期的方式使用合法工具，如删除数据、过度调用付费接口、外传信息；涉及提权归 ASI03，形成代码执行的归 ASI05； 身份与权限滥用（ASI03）：操纵委托链、角色继承与 agent 上下文实现提权；根源是身份体系以人为中心，agent 没有独立受治理的身份，最小权限无法真正执行； 智能体供应链（ASI04）：模型、工具、插件、数据集、MCP 与 A2A 接口、注册表、更新通道等第三方组件被投毒或篡改；与传统软件供应链的差别在组件多为运行时动态装配； 意外代码执行（ASI05）：注入、工具滥用或不安全序列化把文本变成可执行行为，后果是宿主或容器接管、驻留与沙箱逃逸；代码常由 agent 实时生成，绕过基于静态规则的安全管控； 记忆与上下文投毒（ASI06）：对话历史、长期记忆、检索库被写入恶意或误导数据，污染此后的推理、规划与工具选择，跨会话传播；这一类投毒针对存储的上下文，当次输入的注入归 ASI01； 不安全的智能体间通信（ASI07）：多智能体系统的消息交换缺乏认证、完整性与语义校验，可被拦截、伪造与篡改，威胁横跨传输、路由、发现与语义各层； 级联失败（ASI08）：单一缺陷沿智能体网络传播放大成系统性故障；它描述扩散本身而非起点，起点按性质归 ASI04、ASI06 或 ASI07； 人机信任利用（ASI09）：利用拟人化信任、权威偏差与自动化偏差，让人不加验证地批准 agent 的输出与建议，审批链上的人成为被利用的一环； 失控智能体（ASI10）：恶意或被攻陷的 agent 偏离预期功能与授权范围，行为漂移且伪装合规；清单关注漂移开始后的行为完整性丧失，不是初始入侵。 这份清单完成了自己的任务：给做 agent 安全的人当参考，收录影响最大的十类威胁，公开攻击的主要形态都在其中。它的组织方式是威胁类型，不是 agent 内部结构，所以回答不了这样的问题：每一类威胁落在运行时的哪个位置、哪几类威胁共享同一个根因、为什么公开漏洞集中在其中几类而其余几乎为零；回答这些问题，需要的是从结构出发的推导。 ...
AI Agent 安全系列：1. AI Agent 结构拆解
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，仓库携带的 .gemini/.env 配置在沙箱建立前被当作可信配置处理，最终落到容器启动器的命令注入[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 之后都直接参与决定下一步调用哪个工具、传递什么参数，模型把读进的一段文字转成一次工具调用，输入由此从数据变成了决策依据本身。 两种模型的差别如下图： Traditional software Untrusted input web page · email Parser strict format Program logic hard-coded Action render · compute data | control attacker must find a parser or memory flaw to turn data into control flow AI Agent Untrusted input web page · issue · MCP result Model reads content content → decision input Next tool call which tool · what args boundary removed content directly shapes decisions — no boundary between data and control 输入参与决策是第一条事实，权限是第二条。coding agent 通常持有开发者本人的完整权限，从读写文件、执行命令到使用其凭证，这种权限是产品前提而非实现上的省事：agent 要执行业务，就必须持有相应权限。两条事实合在一起，构成 agent 安全的核心问题：不可信内容能够影响决策，决策的执行又携带完整权限，中间的防线是什么、能否有效拦截。输入与执行之间的这些防线，正是 Agent 安全研究的对象。 ...