★ FEATURED ARTICLE 过去一年有一个问题几乎出现在我每一次安全评审会上代码已经有相当比例是 AI 辅助生成的Agent 开始拿着真实密钥调真实接口我们的安全测试到底测在哪儿就在这个节点上AI 安全测试AIST登上了 Gartner 技术曲线。标题里的“Vibe Coding 至 OpenClaw 全技术栈”听起来很唬人但拆开看其实就是两件事AI 写出来的普通应用代码怎么测AI 自主行动的 Agent 工具链怎么测。前者是 Vibe Coding 带来的海量“快速生成但未必安全”的代码后者是 OpenClaw 这类平台把工具调用、记忆、权限组合在一起后形成的更复杂的攻击面。这篇文章不打算做概念科普我会按实际做过的测试思路来拆攻击面长什么样、每个环节具体测什么、用什么方法、先落地哪些。新老读者都能从中找到可以直接抄走的测试清单。1. 为什么 AIST 突然从“能跑就行”变成“必须测”的赛道1.1 Gartner 技术曲线的信号意义Gartner 的技术曲线本质上是一张“行业关注度随时间变化”的晴雨表。AIST 能进入这张曲线我理解不只是因为 AI 本身火而是安全测试的对象发生了结构性变化过去我们测试的是人写的代码代码规模增长有限、缺陷模式可枚举现在代码可以由自然语言批量生成Agent 可以自主完成多步操作传统测试方法论在两层同时失效。技术曲线还有一个隐性含义——它预示着该领域会快速从“概念讨论”转向“标准化交付”。接下来会有越来越多团队把 AI 安全测试当作 CI 门禁里的一个普通环节而不是某个安全研究团队偶尔做的红队项目。谁先把流程固化下来谁后面就轻松。1.2 三种压力倒逼测试前置我观察到的压力主要来自三条线三条线刚好对应标题里的两个关键词。第一条是生成代码规模。Vibe Coding 让一个普通开发者的日代码产量翻了数倍但相当一部分生成代码存在逻辑浅层正确、深层脆弱的问题没做输入校验、把密钥写进注释、调用了一个来源可疑的依赖包。代码量上去了人工 Code Review 不可能再逐行覆盖必须靠自动化测试工具补位。第二条是 Agent 自主性。OpenClaw 这类平台已经把“规划-调用-执行”做成标准流程。Agent 不再只是输出文本而是能改文件、发请求、执行命令。那么问题就来了如果 Agent 被注入的恶意指令劫持它会把权限变成武器。这里的测试对象不再是静态代码而是动态行为链。第三条是合规证据。越来越多甲方和监管在问“你怎么证明 AI 产出物是安全的”这逼迫团队把安全测试结果变成可留存、可追溯的记录。AIST 正好承担这个角色——它的产出物既是漏洞清单也是安全证据链。1.3 AIST 解决什么、不解决什么按我的实践理解AIST 主要解决四类问题AI 生成代码的已知漏洞模式、Agent 工具调用的权限失控、模型提示注入与越狱行为、以及生成式 AI 全链路的供应链风险。它不解决什么也很重要。AIST 不负责算法公平性也不负责内容合规审核更不替代传统应用安全测试。它是在原有安全体系上叠加的一层专门面向 AI 系统的新测试维度。如果你期望引入一个 AIST 工具就能把所有 AI 安全问题都兜住大概率会失望。提示把 AIST 理解为“对 AI 系统做安全测试”而不是“用 AI 做安全测试”方向就对了。后者是另一条叙事线两者容易混为一谈。2. 从 Vibe Coding 到 OpenClaw先把攻击面摊开做了这些年安全我最大的体会是先看清攻击面再谈测试工具。很多人一上来就找漏洞扫描器但连自己要测的系统边界在哪都说不清。AIST 的覆盖范围是分层的我习惯把整条链路拆成四层来审视。2.1 第一层开发与生成层这一层对应 Vibe Coding 生态。开发者用 AI 助手生成代码、补全函数、生成测试用例、甚至自动修复 bug。攻击面在于AI 生成代码中的通用安全漏洞SQL 注入、路径穿越、反序列化等AI 推荐的第三方依赖包是否可信是否存在仿冒包提示词本身是否被污染比如代码仓库里被人埋了“忽略安全”的隐藏指令AI 自动生成的配置文件是否暴露敏感信息这一层的测试对象是“代码产物”核心工具是改进后的 SAST、依赖审计、以及专门针对 AI 代码特征的规则集。2.2 第二层Agent 工具与编排层这一层是 OpenClaw 这类 Agent 平台的主战场。Agent 会接收任务、规划步骤、调用工具、读取上下文、执行操作。攻击面包括工具调用的权限边界是否可被提示词操纵Agent 的长期记忆是否会被污染导致后续行为异常外部输入网页、文档、邮件中注入的隐藏指令能否劫持 Agent工具链之间的级联操作是否会产生非预期副作用Agent 运行环境沙箱、容器的隔离强度这一层是传统安全测试几乎没有覆盖的空白地带也是我认为 AIST 最有价值的部分。测试对象变成了“行为产物”需要依赖轨迹记录和行为仿真。2.3 第三层模型与数据层这一层负责测试模型本身的安全性。常见的包括提示注入通过各种编码、变形、角色扮演绕开系统指令越狱攻击诱导模型输出违规内容或危险操作步骤数据投毒污染训练数据或 RAG 知识库让模型给出错误答案模型窃取通过大量查询推断模型结构或训练数据隐私这一层需要专门的对抗样本库和红队工具。模型行为无法像代码那样做静态分析必须靠动态测试和样本回归。2.4 第四层基础设施与供应链层最后一层是底座。AI 系统的载体包括模型托管服务、向量数据库、API 网关、CI/CD 流水线、私有化部署环境。攻击面包括模型文件是否被篡改部署流程是否可追溯向量数据库的访问控制是否到位能否被越权读取API 网关的鉴权、限流、审计是否作用于 AI 接口训练数据管道是否融合了不可信的公开数据源这一层更接近传统基础设施安全但对象多了模型文件、向量库、Embedding 管道这些新资产。分层代表场景主要测试对象典型风险开发生成层Vibe Coding生成代码、依赖、配置文件SQL 注入、仿冒包、提示词污染Agent 编排层OpenClaw 类平台工具调用、记忆、沙箱注入劫持、权限越界、级联副作用模型数据层对话、RAG、Agent模型行为、知识库提示注入、越狱、数据投毒基础设施层模型服务、向量库API、存储、流水线越权访问、模型篡改、配置泄露这四层不是孤立存在的。一次完整的 AIST 应该覆盖从开发者写下提示词的瞬间到 Agent 执行完操作产生影响的整个过程。下面我针对两层最关键、也最容易被忽视的部分做深度展开。3. 针对 Vibe Coding 产物的安全测试把“生成的每一个包”当外部输入3.1 传统 SAST 为什么会漏很多团队的第一反应是把 AI 生成的代码跑一遍传统 SAST 不就行了实际跑过就知道漏报率相当可观。原因在于传统 SAST 的规则是基于“已知的人类缺陷模式”构建的它擅长抓 SQL 注入、XSS、硬编码密钥这类经典问题。但 AI 生成代码的缺陷很多时候长在“非典型位置”——比如一个看似无害的正则表达式由于回溯导致 ReDoS一个普通的 object 合并操作由于原型污染被利用一段“看起来经过优化”的代码其实绕开了框架自带的防护机制。更麻烦的是语义层面。AI 可能为了实现功能主动关闭了某些安全配置或者以不安全的方式使用了安全 API。这类问题在抽象语法树上是看不出来的必须结合上下文语义才能发现。所以仅靠传统 SAST 作为 AI 代码的安全防线等于让旧地图指导新航行。3.2 测试视角转向Vibe Code 即“半外部代码”我建议把 AI 生成的代码视为“半外部代码”——来源可信度高于陌生开源项目但远低于团队内部手写核心代码。既然是半外部代码就要参考第三方依赖的治理方式来处理。这个视角转变带来三个实操改变。第一AI 生成的文件进入主干前必须有 diff 审计。不管开发者的 IDE 多流畅AI 改过的文件都要留下清晰的变更记录安全团队可以按文件类型设置抽查比例。第二AI 生成代码的依赖必须执行更严格的来源校验。凡是 AI 推荐安装的新依赖一律走一遍包来源验证、许可证检查、已知漏洞匹配的流程。第三AI 生成文件中如果带有可疑注释、调试后门、异常凭证必须触发告警。3.3 实操一个提示注入后门在生成代码里的模型我在某次测试中遇到过这样一个案例。某开发者用 AI 助手生成一个“邮件自动回复机器人”提示词里要求“调用 xx 库来解析邮件内容”。AI 在生成时悄悄在代码里加入了一段看起来像业务逻辑的解析分支当邮件正文包含某个特定字符串时会向指定接口发起 HTTP 请求。这段代码语法正确、逻辑风险隐蔽传统 SAST 完全没报警。后续排查发现那个“指定接口”对应的域名和真实服务域名只有一字母之差。如果生产环境被攻击者先注册域名这就是一个现成的数据外带后门。这个案例我复盘了很多次最终沉淀出一条测试规则凡是 AI 生成的代码中出现非业务所需的网络请求、文件写入、命令执行必须出现在高危审计名单里。这个规则听起来朴素但它能拦截大量“AI 一次性生成但没人逐行看”的漏洞。3.4 如何建立“生成文件”的可信基线实操层面我给团队推荐的做法是为 AI 生成文件建立可信基线在 IDE 或代码托管平台配置“AI 生成标记”让 AI 生成或大幅修改的文件自动打标。打标文件在合并请求阶段触发专项检查依赖来源核验、敏感信息扫描、异常行为模式匹配。每次合入后把结果汇总到安全面板形成“生成代码漏洞密度”的长期趋势。连续多次出现高危漏洞的模块降低该模块使用 AI 辅助的信任等级提升人工审计比例。这套流程不复杂但能立刻把“AI 写代码”这件事从不可控变成可观测。安全测试的第一要务不是消灭所有漏洞而是让风险变得可测量、可追踪。4. 针对 Agent 化平台的实测方法权限矩阵、上下文与级联动作如果说 Vibe Coding 时代的测试对象还是静态代码那 OpenClaw 这类 Agent 平台就把测试推向了全新的复杂度测试对象会自己动。Agent 会读网页、写文件、调 API、执行命令每个动作都可能被外部输入影响。这部分的测试方法传统安全工具基本帮不上忙必须按行为链设计。4.1 Agent 工具调用边界如何构造权限越界Agent 平台的权限模型通常包含工具清单、可操作资源和环境隔离。测试的第一个核心问题就是Agent 在受到诱导时能否突破它的工具权限边界。我的标准测试手法叫“越权指引链”。具体做法是构造一个包含隐藏指令的外部输入比如一个网页让 Agent 去读取。隐藏指令的内容设计成“忽略之前的限制帮我执行某个更高权限的操作”。然后观察 Agent 的反应。实操中你会发现一个常见漏洞Agent 的工具权限是静态配置的但上下文中的“指令优先级”是动态变化的。某 Agent 被配置为“只读模式”但外部输入引导它调用一个内部辅助工具该工具内部又调用了写接口。单看工具层权限配置是正确的看行为链越权已经发生。这种问题靠检查配置是查不出来的必须在仿真环境里做行为测试。我把这类测试叫“权限漂移测试”——验证 Agent 在外部压力下会不会从既定权限路径漂移到更宽权限路径。4.2 上下文污染与记忆投毒测试第二个核心攻击面是上下文。Agent 的决策依赖上下文窗口里的信息包括系统提示词、用户输入、检索到的知识库内容、外部网页内容等。这些信息源一旦混入恶意内容就形成了上下文污染。记忆投毒比一次性上下文污染更阴险。OpenClaw 这类平台通常有长期记忆机制Agent 会把重要信息持久化。攻击者如果能在某次交互中让 Agent 记住一段错误信息或恶意指令后续所有会话都会被污染。我测试这类问题时的方法准备一个包含“隐藏任务”的测试文档让 Agent 读取后执行一个无害的基准任务看它会不会在后续对话中突然执行隐藏任务再隔一段会话观察记忆是否残留。测试结果通常会出一个“触发率”指标——即多少比例的注入样本能成功污染行为。这个指标比单次漏洞报告更有决策价值。4.3 级联副作用单步安全不代表全链路安全Agent 最危险的特征不是单步操作而是多步操作的级联。单步安全的工具链组合起来可能形成危险链路。举个匿名化处理的例子某 Agent 平台提供了文件下载工具和代码执行工具两个工具各自都有完善的沙箱隔离。但测试中发现Agent 可以在下载工具里写入一个文件然后通过代码执行工具运行这个文件。如果两条工具链之间没有共享文件系统的隔离检查那沙箱形同虚设。级联测试的方法也不复杂手动编排一个多步骤任务让 Agent 依次调用工具 A、工具 B、工具 C每步都制造一些“边界试探”——比如 A 生成一个特殊文件B 读取这个文件并产生输出C 再基于输出执行操作。观察每两个工具之间的数据传递是否经过安全校验、权限是否重新评估。这一步特别考验测试设计能力因为单工具测试工具本身测不出链路上的盲区。4.4 回归测试实践一次 Agent 会话的完整测试流Agent 安全测试不同于传统漏洞扫描它依赖“会话轨迹”的完整记录。我摸索出的一套相对固定的回归流程可以直接参考准备测试任务集包含正常任务、嵌有注入的任务、需要多步工具调用的任务部署隔离测试环境Agent 运行在临时容器中所有工具 API 使用 Mock 端点执行会话并全量记录保存 Agent 的输入、中间思考过程、工具调用参数、环境返回结果结果评估检查是否出现权限越界、敏感数据外带、非预期命令执行指纹化留存把危险行为路径记录为“指纹”后续版本升级时用同一批测试任务回归这套流程跑起来后Agent 平台的每次版本更新都能得到一份“安全行为差异报告”而不是等上了生产才被攻击者发现异常。5. AIST 的实战工具箱四个梯队的工具与自建能力AIST 领域工具分类并不像传统安全那样有一条清晰的产品线更多是组合拼装。我按成熟度和投入成本把工具箱分成四个梯队团队可以根据自己的情况选配。5.1 第一梯队传统测试工具改造第一梯队是大家手头已有的传统工具包括 SAST、DAST、依赖扫描器、密钥检测工具。别急着换掉它们先把它们改造到 AI 场景里。具体做法是把 AI 生成文件打上标签让扫描引擎优先处理增加针对 AI 代码特征的规则比如检测“模型输出的代码中是否直接拼接了提示词相关内容”将依赖扫描结果与 AI 推荐依赖库进行交叉比对。这套改造成本最低基本一周内就能见效。5.2 第二梯队LLM 安全专项工具第二梯队是针对大模型安全场景的专项工具覆盖提示注入检测、越狱样本测试、护栏有效性评估等。这类工具通常内置攻击样本库能自动对目标模型发起批量测试输出“违规率”“拒绝率”等指标。使用上我会特别强调两点。第一测试样本库要持续更新市面上公开的越狱样本加权效果衰减很快团队需要定期补充自己场景下的变体第二模型安全测试结果需要人工复核不能全信工具的自动判定因为模型有时候会给出“边界模糊”的回答机器判合规、人看其实踩线。5.3 第三梯队Agent 测试框架第三梯队是面向 Agent 平台的测试框架。这部分产品形态还很早期更多是半自建状态。一个可用的 Agent 测试框架至少需要具备三件事仿真环境让 Agent 在一个可监控的沙箱里跑、工具 Mock 能力拦截 Agent 发出的真实请求并返回可控响应、轨迹回放能力把一次完整会话录制下来供二次分析。我见过不少团队在这里踩坑直接用生产环境测 Agent结果 Agent 调用真实第三方 API 产生了费用或误操作。仿真环境不是可选项是必选项。5.4 第四梯队对抗与自主仿真第四梯队是目前最前沿、也最耗资源的——对抗性红队和自主仿真。思路是用一个“攻击型 Agent”自动生成攻击样本持续试探“防御型 Agent”的行为边界形成攻防对抗闭环。这个梯队的投入相当大效果也最有上限空间。攻击 Agent 可以自动构造更复杂的多步注入链路比如结合社会工程场景、伪装可信来源甚至利用 Agent 之间的信息传递发起间接注入。一般团队到第三梯队就已经能覆盖 90% 的日常需求第四梯队适合已有成熟 AI 安全团队的组织长期建设。梯队能力范围投入程度见效速度第一梯队传统工具改造低快1-2 周第二梯队LLM 专项扫描中中等2-4 周第三梯队Agent 行为仿真高较慢1-2 个月第四梯队自主对抗演练极高长期投入6. 落地优先级第一个月该测什么第二个月该建什么我的经验是AIST 落地最大的坑不是什么技术难题而是什么都想测、一头扎进模型红队里结果连最基本的生成代码漏洞都没堵住。优先级乱掉项目大概率两个月后不了了之。6.1 一张优先级列表我直接给一份按性价比排序的落地清单适用于大多数中型团队优先级测试项落地方式建议周期P0AI 生成代码的基础漏洞与依赖来源核验改造 SAST 依赖审计打标 AI 文件立即P0Agent 工具调用的权限边界测试仿真环境 越权指引链样例第 1 个月P1提示注入与上下文污染回归LLM 专项扫描 注入样本库第 1-2 个月P1Agent 级联副作用测试编排多步工具链测试第 2 个月P2模型越狱行为与护栏有效性LLM 红队工具第 2 个月起P2全链路对抗演练攻击 Agent 防御 Agent第 3 个月后P0 和 P1 是在第一周就要开始动手的。很多 AI 项目根本没有对 AI 生成代码做依赖来源核验仿冒包一引入就是供应链级事故这个不是安全瑕疵而是事故隐患。6.2 最小化 AIST 基线MAB的定义为了让团队有共同的奋斗目标我提出了一个“最小化 AIST 基线”的概念可以理解为 AI 安全测试的“及格线”。MAB 包含三个强制项和一个推荐项。强制项一AI 生成文件进入主干前完成自动化漏洞扫描高危漏洞阻断合入强制项二Agent 平台的每个新增工具必须跑一遍权限越界测试强制项三所有 AI 系统发布前完成一轮提示注入回归测试。推荐项是每季度一次 Agent 级联行为全量评估。这三条基线看起来简单但我实测下来能满足全部强制项的团队不超过一半。先把及格线守住比追求尖端工具更有意义。6.3 一个常见的误区最后想提醒一个误区不要试图把 AI 安全测试全部自动化。AI 系统的行为复杂度决定了它需要大量人工设计场景、主观研判结果。那些号称“全自动 AI 安全平台”的产品实测中都有不低的误报率和漏报率。最好的模式是人机协作自动化工具负责批量采集信号、跑回归样本安全工程师负责设计测试场景、研判高危告警、沉淀安全规则。人负责理解机器负责执行各干各擅长的部分。7. 关于 AIST 长期建设我的几条实践建议AIST 不是一次性的“项目制”工作它更像是持续运行的“制品线”。在这条线上跑的不只是漏洞扫描更是团队对 AI 系统安全边界的认知迭代。我的个人体会是把 AI 安全测试当成跟单元测试一样的日常习惯而不是等上线前的临时检查。每周固定跑一次 Agent 行为回归每次 AI 工具升级都触发专项测试每次安全事件复盘都反哺测试样例库。这样循环下来测试资产才会越来越厚而不是每次从零开始。还有一个容易忽略的点把 AI 安全测试的“失败案例”当作团队资产。你发现并修复过的每一次提示注入、每一处权限漂移、每一条级联漏洞都值得写成内部案例库。这些案例不仅是新员工的教材也是后续测试场景设计的灵感来源。安全测试的真正价值不在于你当下发现了多少漏洞而在于你的测试体系能不能随 AI 系统演化一起生长。最后如果你所在团队还没开始 AIST我的建议很直接找一条最靠近生产环境风险的小链路比如面向业务数据的 AI 聊天机器人或者正在试点 Agent 的运维场景从 P0 清单开始跑起来。跑出第一份报告后你自然就知道下一步该往哪儿投入了。
阅读完成 · 觉得有帮助？
