AI 安全

AI 安全与传统安全的本质差异

AI 安全是一个新的问题。 它不能被简单归入传统安全分支，因为传统安全的前提是系统是确定的、权限有边界、输入输出可预测、人会决策。但在 AI 场景下，这些前提正在逐渐失效。AI 第一次让"认知系统"直接连接了现实执行能力。传统互联网时代，认知在人，执行在机器；AI 时代，认知与执行开始逐渐合并。

传统安全面对的是"确定性程序"，AI 安全面对的是"概率性推理系统"。 传统系统本质是固定逻辑执行，输入和输出之间存在明确映射关系，因此安全问题主要来自漏洞、权限缺陷和非法输入，核心方法是规则、边界和校验。但 LLM 本质是基于概率预测生成结果，同一个输入在不同上下文、历史状态、模型版本、温度参数下，都可能产生不同输出。AI 系统天然不可完全预测，传统"规则式安全"开始失效，安全问题从"程序漏洞"扩展到了"模型行为不确定性"。

传统攻击是在"利用漏洞"，AI 攻击是在"操控认知"。 传统攻击方式如 SQL 注入、RCE、越权，本质都是让程序进入开发者未预期的执行路径。而 AI 攻击方式如 Prompt Injection、Jailbreak、Memory Poisoning，本质从攻击代码转向影响模型的理解、推理和决策过程。攻击者开始从控制系统执行，扩展到"诱导模型相信某件事"，最终影响模型行为。

AI 最大的结构性问题之一，是"数据"和"指令"的边界消失了。 传统系统里，SQL 与数据、Shell 与参数、HTML 与脚本之间都有明确边界，因此可以通过 escaping、parameterization、sandbox 等技术隔离风险。但在 LLM 中，自然语言同时承载数据、指令、权限意图、推理目标等信息，用户输入和系统 Prompt 本质共享同一个上下文窗口。模型无法像编译器一样严格区分"这是数据"还是"这是命令"，因此攻击者可以通过普通文本直接影响模型行为。AI 系统第一次出现了"自然语言即执行环境"的问题。

传统安全控制"权限"，AI 安全开始控制"能力"。 传统系统中，一个行为能否执行，主要取决于权限，例如是否拥有 root、是否具备数据库访问权限。但 AI Agent 出现后，即使模型本身没有高权限，只要它能够调用浏览器、Shell、API、MCP、支付接口等工具，就可能间接获得真实世界执行能力。AI 安全的核心问题开始从"有没有权限"变成"具备什么能力"。

传统系统是"被动执行"，AI 系统开始出现"自主行为风险"。 传统程序不会主动思考目标，只会按照预设逻辑执行，因此安全问题主要来自外部攻击者。但 AI Agent 开始具备任务规划、长期执行、自我修正、多步推理等能力后，系统本身会逐渐出现"自主行为"。这会带来 Goal Drift（目标漂移）、Reward Hacking（奖励黑化）、Alignment Failure（对齐失效）等问题。传统安全很少考虑"系统会不会主动绕过规则"，而 AI 安全必须开始面对这个问题。

传统安全更多是"静态防御"，AI 安全天然是"持续动态对抗"。 传统漏洞修复后，系统通常会进入较稳定状态，因此 SDL、补丁、规则更新是核心机制。但 AI 系统会随着模型升级、Prompt 变化、上下文变化、Agent 工具变化而持续产生新行为，今天安全的 Prompt，明天可能失效；今天安全的 Agent，未来可能学会绕过限制。AI 安全无法依赖一次性治理，而必须建立持续红队、行为监控、Runtime Guardrails、Agent Observability、Alignment Regression Testing 等动态防御体系。

传统安全保护的是"程序系统"，AI 安全约束的是"认知执行体"。 传统安全的核心对象是代码、网络、权限和基础设施，目标是防止系统被攻破。但 AI 系统开始同时具备理解、推理、决策、生成和执行能力，尤其在 Agent 化后，模型会逐渐成为现实世界中的"执行主体"。AI 安全从保护系统本身，推进到约束一个具备认知能力、工具能力和行为能力的执行体。传统安全解决的是"机器会不会被攻破"，AI 安全开始解决的是"机器会不会被操控认知，并进一步影响现实世界"。

信任的感知基础正在失效

Deepfake 动摇的是最基础的信任机制：感官确认。 人类的信任系统在演化上依赖感官——我认出你的脸、我辨认你的声音、我看到你在视频里。这些是安全设计的默认前提，从未被质疑过。

当这个前提失效，所有建立在"感官确认"上的认证流程都需要被重新审视。香港某工程公司员工被深度伪造的 CFO 和高管团队骗走数千万美元。这名员工没有不谨慎，她用来验证身份的手段——视频通话中看到熟悉的面孔和声音——本身已经不再可靠。

这改变的不只是"防钓鱼培训"，而是整个身份验证的设计思路。 任何依赖"人类感官确认"的流程都应该被视为潜在的脆弱点：视频会议里的高管、电话里的同事、音频里的指令。替代方案是带外验证（通过另一个已知可信渠道确认）、加密签名和操作权限系统——而不是"看起来更仔细"。

AI 资产安全

AI 资产安全是在保护"AI 的核心智能资产"。 传统互联网时代最重要的资产是数据、代码、系统，而 AI 时代最重要的资产开始变成模型权重、训练数据、RLHF 数据、合成数据、训练流水线、GPU 集群等。模型权重本身已经具备压缩后的数字智能属性，因此权重泄露、训练数据污染、模型后门、训练链攻击，本质都属于"智能资产攻击"。

模型开源不意味着安全投入可以降级，只是安全重心发生了位移。 对于 MiniMax、DeepSeek、Qwen 这类公司，模型权重只是资产的一部分，甚至未必是最重要的部分。训练集群、GPU 集群、模型仓库、CI/CD 和权限系统仍然是核心资产——攻击者控制训练环境，可以窃取下一代未发布模型、篡改训练过程、注入后门，不需要偷已发布的模型，让一次训练任务失败就可能造成难以挽回的损失。开源的是上一代，值钱的是下一代。 训练数据有时比模型本身更难复现——高质量语料、RLHF 数据、人工标注和合成数据管线往往不开源，即使把权重给你，也很难凭此反推出训练它用了什么数据。

基础模型公司的资产安全是 AI 资产安全的最高形态。 基础模型公司同时拥有大规模算力、高价值模型、训练数据、推理平台、Agent 能力和广泛社会影响力，更接近"云厂商、AI 实验室和关键基础设施"的叠加体。

模型权重、Checkpoint 和微调产物是基础模型公司的核心资产。 风险不仅来自权重文件被直接复制，也来自内部人员外传、训练 Checkpoint 被盗、推理侧模型抽取、蒸馏复制、微调环境泄漏和后门模型替换。模型资产保护需要覆盖权重加密、Checkpoint 保护、GPU 内存保护、Fine-tune 隔离、权重访问最小化、模型水印、模型指纹和推理速率异常检测。

训练数据、反馈数据和合成数据也是 AI 核心资产。 训练数据决定模型能力，也会带来隐私、版权、投毒、后门和数据来源不可信风险。数据资产保护需要覆盖 Data Provenance、Dataset SBOM、数据可信链、数据指纹、自动脱敏、Poisoning Detection 和 Synthetic Data Isolation，避免模型能力建立在不可解释、不可追溯、不可控的数据基础上。

AI 对齐安全

AI 对齐安全是在降低模型产生危险行为的基础概率。 预训练模型的目标是预测下一个 token，并不直接理解什么对人有帮助、什么会造成伤害。对齐训练把模型从"会续写的系统"推向"更像助手的系统"，但它改变的是模型在常见输入下的行为倾向，并没有把模型变成可靠的安全边界。

对齐问题来自训练目标、人类偏好和真实意图之间的错位。 模型学到的是语料中的统计规律，人类标注反映的是评价者偏好，而评价者偏好又不必然等于用户真实意图和长期利益。一个回答看起来礼貌、顺从、流畅，仍然可能是错误的、迎合的，甚至是危险的。

RLHF、Constitutional AI、DPO 和可验证奖励，解决的是对齐信号如何产生的问题。 RLHF 依赖人类偏好反馈，Constitutional AI 把偏好约束显式写成原则，DPO 简化偏好优化过程，可验证奖励把部分任务的反馈从主观评价转为客观验证。它们都能改善模型行为，但都不能消除分布外输入、复杂上下文、工具调用和长期执行中的不确定性。

对齐训练的主要失败模式包括奉承效应、奖励黑客、过度拒绝和目标错置。 奉承效应会让模型迎合用户偏好，奖励黑客会让模型脱离任务本身去优化评价信号，过度拒绝会让模型把合理请求误判为危险请求，目标错置会让模型在"有帮助"和"安全"冲突时做出错误取舍。

对齐只是行为安全的一层概率性防线。 一个已经对齐的模型，在角色扮演、长上下文示例、目标重构、间接提示注入和多轮压力下，仍然可能偏离原有安全行为。AI 安全架构不能把"模型已经对齐"当作前提，只能把它当作一层会失效、可被绕过、需要持续回归测试的控制。

模型供应链会成为 AI 资产安全的一部分。 AI 模型仓库正在经历和 npm、PyPI 类似的供应链污染问题，但规模更难控制。攻击手法包括在模型文件中嵌入恶意代码、注册被删除的热门用户名上传污染版本。模型后门比软件包后门更隐蔽：极少量的训练数据污染就可以植入后门——在标准评估中表现完全正常，但在特定触发条件下持续输出有害内容，无法通过"运行测试"可靠检测，因为后门被设计成只在特定条件下触发。开源模型、微调模型、数据集、Embedding、MCP Server、Plugin、Agent Workflow 和 Tool SDK 都会进入 AI 系统的依赖链，需要像对待第三方代码库一样进行供应链审计，而不是默认信任仓库的存在。

软件包供应链攻击的入口通常不在代码，而在维护者。2025 年 9 月的 npm 供应链事故中，攻击者通过仿冒 npm 官方域名发送钓鱼邮件，构造虚假的二次验证界面窃取维护者凭证，随后一次性污染了 chalk、debug、ansi-styles 等 18 个被广泛依赖的包，恶意代码专门拦截客户端加密钱包交互并重定向支付。攻击者没有触碰任何代码仓库的技术防线，而是通过社会工程学拿下了维护者账号。这说明供应链安全的最脆弱点往往不是技术漏洞，而是持有发布权限的人。

闭源模型公司的重点是保护模型，开源模型公司的重点是治理智能生态。 闭源模型仍然可以依赖 API 边界、访问控制、推理审计和权重保护；开源模型发布后，权重会被本地运行、微调、二次分发和组合进第三方 Agent Runtime。此时安全目标会从"阻止模型被拿走"，转向"保证官方来源可信、模型版本可信、微调链路可信、插件和 Agent 生态可信"。

模型蒸馏防护

模型蒸馏无法被彻底阻止，只能提高成本、降低收益、增加风险。 只要攻击者能调用 API 获取输出，理论上就能通过 Model Extraction 或 Imitation Learning 复制部分能力。类似版权保护的逻辑——目标不是让复制变得不可能，而是让复制变得不经济。

隐藏推理链是最高价值的防御手段。 最终答案的信息量远低于完整的思维链——攻击者拿到"问题 + 推理过程 + 答案"的训练价值，比只拿到"问题 + 答案"高出数倍。这也是近期头部模型普遍开始隐藏 CoT 输出的根本原因：推理过程是比结果本身更高价值的知识。

蒸馏行为和正常用户行为差异显著：调用频率相差数量级，问题分布从集中的日常需求变成刻意覆盖所有领域的系统性采样——数学、法律、医学、编程、创作，尽量均匀分布。这种模式可以形成清晰的检测特征，类似 Anti-Bot 对爬虫的识别，很多公司已把这部分作为独立的异常检测系统建设。

账号与支付风控是实际上拦截最多攻击团队的一层。大规模蒸馏需要大量账号，虚拟信用卡、批量注册、代理 IP 都会留下特征——这和对抗黑灰产的风控逻辑完全一致。行为指纹（Behavior Fingerprinting）比输出水印更现实——用特定设计的探针问题构建被蒸馏方的行为指纹，再拿竞争模型做对比，相似度过高时可提供存在蒸馏的间接证据。ToS 法律约束是技术防不住时的补充工具。

对 AI 爬虫的防御需要区分三类性质不同的流量：训练爬虫（GPTBot、ClaudeBot 等）系统性采样网页内容用于模型训练；实时检索爬虫在用户查询时抓取最新内容补充训练数据的时效盲区；AI 推荐引流则是通过 AI 生成的推荐链接到达的真实人类用户。全面封锁 AI 爬虫类似于早期互联网封锁搜索引擎——会切断潜在的曝光渠道。更合理的策略是按路由选择性限制：登录、支付、管理后台等敏感路由应拒绝所有爬虫访问；内容、文档、博客类路由对合规训练爬虫保持开放。针对蒸馏的防御应聚焦在 API 调用行为异常检测（覆盖采样模式）和账号风控层面，而不是简单屏蔽所有 AI 流量。

最重要的护城河是迭代速度，而不是防蒸馏技术。 如果蒸馏当前版本需要数个月，而被蒸馏方数个月后已经发布下一代，模仿者永远追的是上一代。头部模型公司真正的优势在于数据体系、RL 训练能力、研究团队和工程迭代速度的组合——这些无法通过蒸馏 API 输出来复制，蒸馏只能复制当前模型的部分能力，无法复制背后使这个能力持续演进的系统。

AI 内容安全

"内容安全"在不同视角下指的不是同一件事，先把它拆清楚。

**内容安全（Content Safety）**关注模型输出了什么——色情、暴力、恐怖主义、自伤、网络攻击内容。这是监管看到的维度，也是技术团队日常建设的对象。**信任安全（Trust & Safety）**关注用户和社会如何感知模型——深度伪造、虚假信息、舆论操纵、品牌攻击。**行为安全（Behavior Safety）**关注 AI 会做什么——自动发邮件、执行代码、完成转账。

这三者的边界在真实事故中容易被混淆。假设某模型的违规输出率极低，但攻击团队通过多轮对话加特殊编码找到一个成功率极低的 Jailbreak，批量录屏后全网传播——技术上这是内容安全的边缘失守，CEO 看到的是品牌危机，CISO 看到的是攻击面被利用。这类"对抗性声誉攻击"的本质是 Model Abuse 与 Trust & Safety 风险，而不仅仅是内容安全技术指标的失败。

内容安全防御体系已相对成熟，防御逻辑从训练到输出形成闭环。

最底层是训练对齐：让模型从根本上不倾向于输出有害内容。训练数据中系统性地加入危险问题、恶意请求、越狱案例和红队样本，配合期望的拒绝或替代性安全回答。这是所有防御的能力基础，但单靠训练不够——它无法覆盖无限变化的攻击提示词。

输入检测在请求进入主模型之前做第一道拦截，用专门的安全分类模型判断请求类别和风险等级。Jailbreak 和 Prompt Injection 检测是输入安全的独立子层——角色扮演绕过、编码攻击、翻译攻击、"开发者模式"类提示，这些有足够多的特征模式可以单独建模识别。

在实践中，输出检测是最实际依赖的防线。 无论训练多完整、输入过滤多严格，总有漏网之鱼。在模型输出到达用户之前再过一次审核，是最可靠的兜底机制。

风险分级响应比二元拒绝效果更好。 更有效的策略是按风险级别调整输出——低风险正常回答，中风险只提供原理和背景，高风险只讲防御不讲操作，极高风险才直接拒绝。这样既保留了模型的有用性，也减少了过度拦截带来的副作用。

在线红队与反馈闭环是最容易被忽略的一层。 线上每天出现大量新绕过方式，没有任何静态模型能持续应对。需要把用户反馈、自动聚类、红队分析、训练数据更新和模型迭代形成完整闭环——这是内容安全体系的持续运营能力，而不是一次性工程。

三类安全的优先级因公司类型而异。对金融机构而言，行为安全优先于内容安全——用户宁可看到一句不合适的话，也不希望 Agent 执行了一笔错误的转账。对 MiniMax、OpenAI 这类 ToC 模型公司，信任安全与内容安全权重相当，因为最大的损失往往来自热搜、媒体和监管，而不是技术漏洞本身。

内容安全最终会从"核心挑战"变成"基础能力"。 越来越多的事故来自 AI 的行为而非内容：推荐诈骗话术、自动发送钓鱼邮件、完成有害工具调用链。未来安全重心将向 Intent Safety 和 Agent Safety 移动，内容安全类似今天互联网公司的敏感词和审核系统：必须做好，但不是最难的那件事。

AI 行为安全

AI 行为安全是在约束"AI 从目标形成到现实行动的完整行为链"。 AI 最大风险已经从"模型本身"，延伸到模型在 Runtime 中如何理解上下文、形成目标、拆解任务、调用工具、写入记忆、影响用户和改变外部系统。尤其 Agent 化之后，AI 会具备长期记忆、任务规划、Tool Use、自动执行等能力，因此攻击目标也从"系统权限"变成"AI 行为控制权"。

AI 行为安全的核心判断是：模型生成的意图能否被直接转化成不可控执行。 Prompt Injection、Jailbreak、RAG 污染、Tool Injection、Memory Poisoning、Agent Manipulation，表面形式不同，本质都是通过改变模型的认知、目标、推理或执行路径来夺取行为控制权。

Agent 攻击面覆盖完整认知链路。 认知输入攻击污染 Prompt 和 Context，记忆攻击污染长期偏好和策略，知识库攻击污染 RAG 召回内容，工具攻击诱导危险 Tool Use，权限攻击放大用户和系统权限，规划攻击劫持任务拆解，多 Agent 攻击污染信任链，输出执行攻击把错误内容转化为真实动作。

AI 输入安全

AI 输入安全是在防止 AI 在"理解世界"阶段被操控。 传统系统中，输入只是数据；但在 AI 系统中，输入同时可能承载指令、目标、权限、身份、上下文、环境信息与推理路径。AI 输入安全本质是在解决：AI 是否正在被诱导形成错误目标、错误认知、错误推理。

AI 输入安全也要防止敏感数据被错误带入上下文。 企业接入 AI 后，代码、财务数据、用户隐私、内部文档、客服记录、工单、日志和知识库都会进入模型上下文或长期记忆。员工把内部资料直接喂给外部模型，RAG 把无权访问的文档召回给 Agent，Memory 记住敏感偏好或业务秘密，本质上都是数据边界被 AI 绕开。

其中最核心的问题包括：

Prompt Injection

Prompt Injection 的本质是用自然语言修改 AI 对规则、身份和任务边界的理解。 直接提示注入来自用户输入，间接提示注入来自网页、邮件、文档、RAG 结果、工具返回值和其他 Agent 消息。后者对 Agent 更危险，因为攻击者不需要直接接触模型，只要污染模型会读取的环境内容，就可能把数据变成指令。

提示注入难防，是因为模型缺少可靠区分指令来源的机制。 系统提示、用户输入、工具结果、网页正文和长期记忆最终都会进入上下文窗口。模型被训练为根据上下文生成输出，但它很难像操作系统一样强制执行"系统指令高于工具返回、工具返回只能作为数据"的安全边界。

Prompt Injection 很可能是 Agent 时代的"SQL 注入"，但比 SQL 注入更难彻底防御。 SQL 注入攻击的是有明确语法边界的解析器，修复路径清晰。Prompt Injection 攻击的是模型的认知系统——攻击者只需要找到让模型改变行为的自然语言表达，而这个空间是开放的，不存在百分之百的防御方案。

行业普遍采用纵深防御：假设注入一定会发生，用多层机制限制注入成功后的损害半径。 这和现代网络安全从"防入侵"转向"假设失陷（Assume Breach）"的演化路径一致。权限最小化和高风险操作人工确认，这两层往往能拦截绝大多数实际损害，其余几层主要提升整体鲁棒性。

数据与指令分离降低注入成功率。用结构化标签显式隔离来源——系统提示、用户输入、RAG 结果、工具返回各自打标——可以给模型提供更清晰的优先级信号，降低检索内容里嵌入的指令被当作命令执行的概率，但不能彻底消除风险。

工具权限网关在 LLM 与工具 API 之间加一层显式检查。模型生成工具调用之后，不直接执行，先经过网关做风险评分、权限核验、必要时触发人工确认，再决定是否放行。这把"模型判断"和"实际执行"解耦，攻击者即使控制了模型的输出，还需要穿过另一层独立的策略检查。

AI 行为检测是目前最值得投入的防御方向。 单个工具调用往往合法，但异常调用链会暴露被控的 Agent：查询日历 → 读取通讯录 → 向外部地址发邮件 → 下载文件，每步都可能通过权限检查，组合起来是明显的渗漏行为。这和 EDR 从"检测恶意文件"转向"检测异常进程行为链"的思路完全一致——是 Agent 安全的自然延伸，也是传统安全体系最难覆盖的新攻击面。

对于高价值系统，防御优先级应是：权限最小化 → 工具权限网关 → 人工确认 → AI 行为监控 → 数据指令分离 → 注入检测。

Jailbreak

Jailbreak 是通过复杂上下文、角色扮演、分步诱导、长上下文示例和目标重构绕过安全约束。 越狱说明现有对齐更多是在改变行为概率分布，并没有在模型内部建立稳定价值判断。当攻击构造出足够强的反向上下文时，模型可能从安全行为回落到未对齐行为。

目标注入（Intent Injection）

目标注入是直接向 AI 注入危险目标。 例如诈骗、绕过风控、恶意自动化、攻击等行为。攻击者也可以将危险目标包装成"安全研究""内部调试""压力测试"等合法场景，从而绕过意图识别。

目标拆解（Goal Decomposition Attack）

将危险目标拆解成多个局部无害步骤，使 AI 丧失整体风险感知。 例如分别询问页面构造、邮件发送、可信度提升等步骤，最终组合成完整钓鱼攻击链。

身份与权限污染

让 AI 错误理解"自己是谁""当前是否拥有权限""当前是否已授权"。 例如诱导 AI 认为自己是管理员、当前环境是测试环境、允许读取所有数据。

环境与上下文污染

环境与上下文污染是通过污染网页、搜索结果、RAG、Memory、向量数据库、长期历史等外部知识源，持续影响 AI 对世界的理解。 这类攻击更像"慢性认知污染"。长期运行的 Agent 如果把被污染内容写入记忆、工作文件或数据库，污染会跨任务延续，并在后续执行中重新触发。

知识库攻击是企业最容易低估的上下文污染。 很多系统默认内部知识库可信，但 RAG 本质上会把知识内容转成 Prompt 的一部分。只要恶意文档、错误 Chunk 或被污染的向量召回进入上下文，Agent 就可能把知识当成指令，把检索结果当成更高优先级的任务要求。

RAG 和向量库要按可执行上下文治理。 RAG 看起来是知识检索，本质是把外部数据拼接进模型上下文。恶意文档上传、Chunk Injection、Embedding Pollution、Retrieval Hijacking、向量库权限失控和跨权限召回，都应被视为输入安全风险。

推理链操控（Reasoning Manipulation）

推理链操控会让 AI 在看似合法的目标下形成危险策略。 例如为了提高效率绕过审核、为了提高收益诱导用户、为了完成任务突破权限边界。攻击者也可以构造虚假的目标优先级，诱导模型把"完成任务"置于"保持安全"之上。

长期目标漂移（Goal Drift）

长期运行的 Autonomous Agent 会逐渐偏离原始目标。 开始可能只是局部优化，最终却可能演化出危险行为。

未来 AI 越来越依赖长期上下文、外部知识、环境反馈与多步推理，因此 AI 输入安全将逐渐从"输入过滤"演化成"认知环境治理"。

AI 运行安全

AI 运行安全是在保护 AI Runtime 本身，防止 AI 在执行阶段产生危险行为。 真正危险的 AI，是"会执行"的系统。当 AI 拥有 Browser、Shell、MCP、支付接口、数据库、云资源等 Tool Use 能力后，就开始具备现实世界执行能力。因此攻击目标开始从"系统权限"转向"行为控制权"。

AI 基础设施安全

AI 基础设施安全是在保证 AI 系统可以被稳定、隔离、可审计地运行。 AI 运行环境依赖 GPU 集群、Kubernetes、模型服务平台、Prompt 网关、MCP Runtime、Agent Runtime、API Key、Token、镜像和依赖供应链。这一层的风险来自算力资源被滥用、模型服务被刷爆、Agent Runtime 越权、租户隔离失效、凭证泄漏和推理链路不可追溯。

AI 基础设施安全要把传统云原生安全推进到模型和 Agent 运行环境。 云安全、主机安全、容器安全、DevSecOps、IAM、Zero Trust 仍然有效，但它们需要覆盖模型调用鉴权、推理配额、Prompt 网关策略、工具调用链路、MCP Server 暴露面和 Agent 执行环境。

AI 基础设施的关键控制点是隔离、配额、凭证和审计。 GPU、模型服务、向量库、工具服务和外部 API 都要有明确的租户边界、调用限额、最小凭证和完整日志。否则攻击者即使没有拿到模型权重，也可能通过刷推理、滥用工具、窃取 Token 或污染执行环境造成真实损害。

Agent IAM（身份与权限控制）

Agent 时代最大的权限误区，是把 Agent 当作代码而不是身份实体。 传统 IAM 管理的是"用户能做什么"；Agent IAM 需要回答四个问题：谁可以创建 Agent、Agent 可以代表谁、Agent 可以做什么、Agent 实际做了什么。当 Agent 开始具备自主执行能力，它就不再是被调用的函数，而是一个需要独立身份、独立凭证、独立审计的执行主体。

Agent 身份攻击包含几种主要形式。Agent 冒充类似钓鱼网站——攻击者创建与官方 Agent 高度相似的名称，诱导用户授权。Agent Token 盗用是传统凭证窃取在 Agent 侧的映射——一旦获取 API Key、OAuth Token 或 MCP Token，攻击者可以伪装成合法 Agent 访问各类系统。Agent 会话劫持在用户与 Agent 之间插入恶意 Agent，形成中间人结构。Fake MCP 注入是 MCP 时代特有的攻击面——攻击者提供伪造的 MCP Server，在工具返回结果中嵌入恶意指令，Agent 信任 MCP 返回值于是执行。

Agent 权限攻击更值得关注。权限提升指 Agent 通过提示注入或授权逻辑绕过，从受限权限扩展到高风险操作。权限继承攻击利用多 Agent 协作中权限叠加的逻辑——Agent A 有读权限，Agent B 有写权限，组合调用产生新的攻击面。Confused Deputy 是 Agent 时代最现实的权限问题：用户本身没有权限，但诱导拥有权限的 Agent 代为执行，就可以绕过权限边界——用户请求 Agent 查看无权访问的数据，Agent 忠实执行，事故就发生了。这个问题在 AI 时代会大量爆发，因为 Agent 天然倾向于"帮助完成任务"，而不是主动质疑请求的合法性。授权策略绕过则通过拆分请求、改变操作描述绕过授权规则，例如把危险操作伪装成测试请求、把大额转账拆成多次小额。

防御的核心思路：Agent 应该被视为会思考的 Service Account，而不是拥有自主数据权限的超级用户。

身份层面，每个 Agent 应有唯一 ID、唯一证书、明确 Owner，类似员工工号体系。Agent 之间的认证参考 SPIFFE/SPIRE 思想，用 mTLS 和证书做零信任认证，不依赖 IP 地址信任。

权限层面，Agent 权限必须比人更严格——很多 Agent 应该默认只读。按角色设计 Agent RBAC（客服 Agent、研发 Agent、审批 Agent 各有不同权限集合），高价值业务进一步引入 ABAC（基于 Agent 身份、用户身份、时间、数据分类、操作目的的多维度授权决策）。AI 权限体系应从用户完整授权转向 Tool-scoped Token、Just-in-time Permission 和任务级授权，让 Agent 只能在被批准的意图范围内行动。

数据授权是 Agent 权限最容易被忽视的一层。 很多团队的权限控制做到"Agent 可以调用接口"就停了，但真正危险的是"调用接口后能看到哪些数据"。这两者必须彻底分离。权限判断不能委托给 Agent 自己——理由和不能让前端做权限控制一样：永远不要相信 Agent 自己做权限判断。

正确的架构是在数据层强制执行：Agent 请求经过 Authorization Layer，带着用户身份（而不是 Agent 身份）到达数据库，数据库只返回该用户有权看到的部分。Agent 最终只能看到它所代理的用户有权看到的内容，不能因为 Agent 有工具调用权限就拿到所有数据。

落地方案有三条路径：User Context Propagation——在整个调用链（用户→Agent→工具→数据）中始终传递用户身份，数据层基于用户身份而非 Agent 身份做权限判断；数据库 RLS（Row-Level Security）——即使 Agent 上层逻辑被绕过，数据库级别的行级权限也能保证数据不越界返回，这是最可靠的兜底；统一 Policy Engine（OPA、Cedar、Zanzibar 等）——集中管理授权逻辑，形成跨系统的一致授权策略。

更进一步是 Purpose-Based Access Control（基于目的的访问控制）：不只判断"谁"和"什么权限"，还判断"为什么"。同样的客服 Agent 查询用户数据，处理工单时允许，批量导出时拒绝。这已经接近金融风控的思路，也是 Agent 权限管理的最终形态。未来最大的 Agent 数据泄露事故，大概率不会来自 Prompt Injection，而来自一个更简单的问题：Agent 被授予了查询权限，但没有把用户上下文和数据范围带到数据层。

Agent 凭证安全

Agent 凭证泄露的根因不是 Prompt Injection，而是错误的凭证设计——把 Token 放进了 Agent 能看到的上下文。 模型能看到的内容，理论上都可以被诱导泄露。Prompt Injection 只是触发机制，真正的漏洞是凭证出现在了 LLM 的上下文窗口里。

核心原则：Agent 应该拥有能力（Capability），而不应该拥有秘密（Secret）。 这是"Use Without Access"原则在 Agent 安全中的具体体现：Agent 可以调用工具、发起操作，但永远不知道背后使用的是哪个 Token、哪个密钥。类似你用支付宝付款时拥有付款能力，但不知道背后的 HSM 密钥和签名私钥。

一个判断系统是否安全的测试：假设把模型替换成一个完全恶意的 LLM，它能拿到哪些凭证？ 如果答案包括 GitHub Token、AWS AK/SK、数据库密码、K8S Token，架构已经有严重问题。正确答案应该是一个都拿不到——因为这些凭证从未出现在 Agent 的上下文中。

Proxy Pattern 是最常见的落地方式。 Agent 只能调用内部工具接口（如 list_repo()），不能发起任意 HTTP 请求。内部接口持有 Token，在 Tool Gateway 内部完成凭证注入和实际调用，Agent 的输入输出中没有任何凭证信息。这是 API Gateway 思想在 Agent 层的自然延伸。

OAuth Delegation 让 Agent 代表用户而不是代表平台行事：用户通过 OAuth 授权，Access Token 存储在 Vault，Agent 调用工具时系统自动取 Token 完成调用，Agent 全程不可见 Token。这避免了平台超级 Token 的滥用——即使 Prompt Injection 成功，攻击者拿到的也只是受限于该用户权限范围内的委托权限，而不是平台级别的全局访问。

STS 临时凭证是更进一步的防御——即使凭证泄露，短时效的临时 Token 在数分钟内自动失效，大幅降低攻击窗口。未来 Agent 系统应该大量使用 STS、OIDC、Workload Identity，而不是长期 Token。

工具输出脱敏防止凭证通过工具返回值间接泄露。Agent 执行 env、kubectl describe、git config 等命令时，返回结果中可能包含 Token，Tool Gateway 必须对输出做 Secret Detection——自动识别并打码符合凭证格式的字段（如 ghp_、AKIA、sk- 等特征前缀），类似 DLP 在 Agent 侧的应用。

TEE（可信执行环境）是高级方案：将 LLM Runtime 和 Credential Runtime 彻底隔离，凭证的持有和使用只发生在 TEE 内部，Agent 无法读取，类似 Apple Secure Enclave 持有私钥但对手机上运行的 App 不可见。

最终的架构目标：即使 Prompt Injection 完全成功，攻击者获得的也只是一个被关在笼子里的 Agent，而不是 GitHub Token、数据库密码或支付密钥。

沙箱隔离

沙箱解决的是 Agent 执行环境安全，而不是 Agent 权限安全，这两者完全不同。 沙箱能限制 Agent 对服务器的破坏范围——被控制的 Agent 执行 rm -rf / 只能删掉沙箱内容，访问 169.254.169.254 被网络策略阻断。但沙箱无法阻止权限合法范围内的危险操作：Agent 用 CRM 权限查了 CEO 工资、用支付接口给攻击者转账、把百万条客户数据摘要输出——这些都是"业务逻辑在执行"，沙箱视角下完全合法。

沙箱主要防四类风险：代码执行（CPU/内存/时间限制防止恶意代码打满资源）、文件系统攻击（危险操作只影响临时目录）、网络攻击（白名单外的内网扫描被阻断）、供应链污染（恶意 npm 包读取环境变量被隔离）。沙箱防不了的：越权查询（权限本来就存在）、Prompt Injection 诱导的合法工具调用（逻辑正确）、API 权限范围内的数据泄露、以及所有由业务授权驱动的危险操作。

因此 Agent 安全应分四层：Runtime Security（沙箱，防服务器被攻击）、Identity Security（Agent IAM，确认 Agent 是谁）、Authorization Security（Policy Engine，控制 Agent 能访问什么）、Behavior Security（风险引擎，判断 Agent 为什么这么做）。对金融场景而言，沙箱通常只覆盖少部分风险，真正决定是否发生资金损失或数据泄露的是后三层。

更重要的架构选择是：能力级（Capability-Level）沙箱，而不是 Agent 级大沙箱。 把整个 Agent 放进一个 Docker 容器，浏览器、代码执行、Shell、文件访问、网络访问都在同一环境——攻击者一旦通过浏览器突破，就可能横向移动到代码执行和文件系统，攻击面等同于一个大 VPC。

能力级沙箱把每种能力放进独立的小沙箱：Agent 打开浏览器时分配一个 Browser Sandbox，执行代码时分配一个 Code Sandbox，运行 Shell 时分配一个 Shell Sandbox，三者彻底隔离。Prompt Injection 成功后攻击者控制的是浏览器，但浏览器和 Shell 之间没有通道，攻击面被切碎了。更进一步是每次 Tool Call 一个沙箱——调用时创建、完成后销毁，类似 Serverless 思想，这已经是 Cursor、Claude Code 类产品的发展方向。

从信任边界角度看，Agentic 系统中存在四个信任层级不同的主体：Agent（LLM 推理运行时）——本身可以像后端服务一样被信任，但受 Prompt Injection 影响，只应按需知原则接收信息；Agent Secrets（凭证）——永远不应暴露给 Agent 可见的上下文；Generated Code（Agent 生成并执行的代码）——最不可预测的主体，能做语言运行时允许的一切；Filesystem/Environment（底层基础设施）——不能给 Agent 完整访问权或任意代码执行权。安全边界必须针对每个主体的特性独立建立。这四个主体中，Generated Code 的安全边界最难推理——正是因为它，"Agent 计算"与"沙箱计算"的分离将成为 Agentic 系统的标准架构：Agent 等待 LLM 响应，生成的代码在按需创建、执行后即销毁的隔离 VM 中运行，两者之间没有凭证共享通道。

网络策略应默认拒绝，只开放白名单域名；文件系统应参考 Chroot 思想，Agent 只能访问任务专属目录；浏览器应做进程级隔离，每次任务创建独立实例并在结束后销毁。攻击者最终控制的不是 Agent 本身，而是 Agent 的某种能力——能力隔离，是限制攻击影响面最有效的手段。

Tool Use 安全

Tool Use 安全包括 Browser、Shell、API、MCP、数据库、支付接口等工具调用安全。 工具参数需要独立校验，工具返回结果应被视为不可信数据，不能自动升级为系统指令。高风险工具调用需要明确授权，涉及外发、删除、支付、发布、改权限和部署的操作需要人工确认。

执行链路控制

执行链路控制包括 Workflow、任务编排、多 Agent 协作、长期任务执行等行为链控制。 多 Agent 系统中，来自其他 Agent 的消息不应天然获得更高信任级别，除非存在可验证的可信通道。协调者读取子 Agent 结果时，也要把结果当作数据处理，避免一个被污染的子 Agent 把恶意指令传染给整个执行链。

可观测与审计

可观测与审计包括 AI 行为链、工具调用链、上下文、推理路径、执行记录等可追踪、可回溯、可审计能力。 审计的目标要从记录最终回答，推进到还原 Agent 为什么形成某个目标、读取了哪些上下文、调用了哪些工具、产生了哪些副作用。

Prompt 审计和 AI DLP 是运行安全的一部分。 数据一旦进入外部模型、Prompt 日志、向量库或长期记忆，就可能脱离原有的数据权限和审计体系。AI 网关、Prompt 审计、数据分类分级、AI DLP、向量库权限、RAG 数据准入和长期记忆写入控制，应该进入运行时链路，并和数据治理制度形成闭环。

Runtime Guardrails

Runtime Guardrails 包括运行时行为约束、动态风险检测、实时拦截与风险终止机制。 Guardrail 不应停留在内容过滤层，还要覆盖检索、推理、调用、写入、提交、发布、外联和记忆更新这些行为节点。

新 Guardrail 规则的上线应遵循 Shadow Mode 策略：先以仅记录模式运行（不拦截），通过数据分析评估误报率和覆盖准确性，确认后再灰度启用拦截。同时对所有经过的事件保留完整历史，支持对新规则做历史回放验证——在沙箱中模拟新规则对历史流量的实际效果，才能在正式启用前消除误杀风险。这和传统 WAF 规则上线要先 log-only 再 block 的原则一致，但在 AI 系统中尤其重要：因为 AI 行为的多样性远高于 HTTP 请求，误报的代价更大。

记忆安全

记忆攻击是 Agent 安全里最被低估的领域，因为它改变的不是当前行为，而是 Agent 对世界的长期理解。 Prompt Injection 是瞬时攻击——会话结束后状态消失，攻击者明天还得重来。记忆攻击一旦成功，污染持续数月，从攻击效果上更类似传统安全中的持久化后门，而不是一次漏洞利用。

记忆攻击有五种主要形式：Memory Poisoning——诱导 Agent 把错误信任关系存入长期记忆，数月后攻击者控制被标记为"可信"的资源时，Agent 仍然信任。Fake Fact Injection——向 Agent 注入错误事实，Agent 在后续回答中持续使用污染后的知识。Privilege Memory Attack 是目前最危险的形式：诱导 Agent 记住"以后支付操作无需确认""我已获得管理员授权"等偏好，本质上是把 ACL 写入了错误内容，后续所有操作都会绕过原有审批流程。Relationship Poisoning——将攻击者的联系方式绑定到受信任身份，Agent 日后可能把敏感信息发送给错误的人。Memory Backdoor——植入条件触发规则，平时完全静默，当特定关键词出现时激活执行恶意动作，类似模型后门但存在于记忆层。

从传统安全视角看，长期记忆就是 Agent 世界的"注册表"和"启动项"。 拿到 Root 和植入启动项后门是两件性质不同的事，后者往往更危险——它持续生效、难以发现。攻击者对 Agent 最有价值的操作，不是诱导它当场执行一个危险动作，而是让它永久相信一件错误的事情。

防御的起点是把记忆分类管理，而不是用一个统一的 Memory Store 让 Agent 随意写入。 用户偏好、知识记忆、策略记忆（支付规则、审批规则）、凭证关系（身份绑定）应该彻底隔离存储，权限各不相同。Agent 可以修改用户偏好，但绝不能直接修改支付策略和授权关系——高价值策略类记忆应该只能由系统写入，或经过人工审批后写入。

记忆写入需要风险分级：低风险写入直接执行，涉及信任关系和业务规则的写入需要用户确认，涉及安全策略和授权关系的写入需要人工审批。Memory Risk Engine 在写入前做风险评分，识别"以后不要审批"、"始终信任"等高风险写入意图并拦截。

Memory Signature 给每条记忆标记来源（系统写入 / 用户写入 / Agent 写入），Agent 读取时能判断可信程度，类似软件签名验证来源。配合 Memory TTL 自动过期机制，避免旧记忆长期积累——临时状态类记忆应该自动失效，不应永久保留。Memory Audit 记录每条记忆的写入者、时间、修改历史，当 Agent 做出异常决策时能通过审计链路追溯到驱动它的那条被污染的记忆，类似 Git History。

AI 输出与反馈安全

AI 输出安全是在防止模型把错误、迎合或危险内容传递给用户和下游系统。 输出本身可能影响用户判断，也可能被其他系统、其他 Agent 或自动化流程继续消费。一个看似只是"文字"的错误判断，一旦进入工作流，就会变成后续执行的输入。

反馈安全是在防止错误反馈继续强化错误行为。 用户认可、系统奖励、工具返回、执行结果和记忆写入都会影响模型下一轮行为。如果反馈信号被污染，Agent 会把错误经验固化成策略，并在后续任务中重复使用。

验证要优先于信任。 代码 Agent 的输出要通过测试验证，数据分析 Agent 的结论要通过可复算样本验证，研究 Agent 的关键引用要独立核查。看起来流畅、合理、礼貌的回答，不应直接被当作可信结论。

AI 长期行为安全

长期行为安全关注模型在多轮任务、长期记忆和持续运行中的风险累积。 单次对话安全，不代表长期 Agent 安全。目标漂移、错误记忆积累、奖励黑客、环境污染、多 Agent 信任链和权限逐步扩大，都会让系统从局部风险演化为结构性风险。

长期 Agent 需要持续回归测试和行为复盘。 每次模型升级、Prompt 调整、工具变更、记忆策略变化和权限扩大，都可能改变系统行为。AI 安全测试要从验证"当前提示是否安全"，扩展到验证多轮交互、异常反馈、工具失败、外部内容污染和用户压力下的行为稳定性。

未来攻击者真正争夺的，会从服务器 root 权限扩展到 AI Agent 的行为控制权。 一旦攻击者能够影响 Agent 的行为链，就可能间接获得现实世界执行能力。

AI 应用安全

AI 应用安全是在保护业务系统接入 AI 后的新风险边界。 AI 客服、AI Coding、AI 风控、AI 搜索、AI 审核、AI 办公助手、AI 浏览器和 AI OS，都是把模型嵌入业务流程、权限体系和用户交互中。风险会从模型输出扩展到业务规则绕过、错误决策、自动化误操作和合规责任。

AI 应用安全的核心问题是输出是否可信、动作是否合规、业务规则是否可被绕过。 AI 客服可能被诱导泄露优惠、修改订单或绕过风控，AI Coding 可能生成漏洞代码、引入恶意依赖或固化不安全模式，AI 搜索和 AI 审核可能把错误判断变成业务决策。应用层需要把模型输出放回业务状态机、权限体系、风控策略和人工复核中验证。

AI 应用安全需要把模型能力变成受控业务能力。 模型可以参与理解、生成和建议，但涉及资金、权限、身份、数据外发、内容发布、代码提交和生产变更的动作，需要通过业务规则、行为白名单、风险评分、人工确认和可追溯执行链约束。AI 接入越深，越需要把"模型会做什么"转化为"系统允许它在什么条件下做什么"。

AI 安全控制层不应成为唯一的认证和授权防线。 2025 年 Next.js 中间件认证绕过漏洞（CVE-2025-29927）揭示了一个通用教训：框架内部用于防止递归调用的 header 没有对外部输入做校验，攻击者伪造该 header 即可绕过所有中间件层的认证逻辑——而使用平台托管的应用因为路由架构与中间件解耦天然免疫。对 AI 应用的启示：Prompt Guardrail、输入过滤、输出审核这些 AI 层面的安全控制，类似于框架中间件，不应是业务逻辑的唯一安全边界。业务权限校验、数据访问控制、操作审批必须在更底层独立执行，而不依赖 AI 安全层是否正常工作。此外，AI 系统内部用于控制流程的实现细节（如内部状态标记、系统 Prompt 中的控制指令）一旦暴露为外部可控输入，就会成为攻击向量——这与框架内部 header 被外部伪造的漏洞模式完全一致。

AI 辅助代码审计

AI 在代码安全审计上解决了传统工具的核心瓶颈——语义理解，但引入了新的盲点。 传统静态分析工具依赖规则和模式匹配，无法理解业务语义，因此很难处理业务逻辑漏洞。AI 可以理解代码意图，大幅提升对这类漏洞的识别能力。

但 AI 的判断质量高度依赖上下文完整性。多参数复杂调用链、跨文件依赖、配置分支和三方包语义这类问题，在上下文不完整时仍然判断不准。更重要的是：安全专家经验、企业规范和业务上下文，这些信息通常存在于文档、口头规则和历史事故记录中，而不在代码里。如果这些信息没有被显式化地传入安全 Agent，模型只能依靠通用训练知识来做判断，而通用知识不了解你的具体业务。

有效的 AI 安全审计需要把专家知识显式化，而不是期待模型自己推断出来。 这是一个工程问题，而不只是模型能力问题。需要被显式化的主要有三类：

• 企业安全规范：哪些 API 调用需要鉴权、哪些数据不能出现在日志里、哪些操作需要二次确认——这些规则通常存在于文档和口头约定里，需要结构化写进安全 Agent 的上下文
• 历史漏洞和事故模式：过去出现过什么类型的安全问题、在哪些代码路径下容易出现、修复时踩过哪些坑——这些是通用模型不具备的领域记忆
• 业务上下文：这段代码处理的是什么业务数据、调用方是谁、在什么权限下运行——没有这些信息，模型只能按语法判断而无法按语义判断

安全 Agent 的质量上限，取决于这些知识被沉淀得有多完整，而不只是用了什么基础模型。

安全介入点一直在向前移动：从上线后修复，到上线前审计，到设计阶段评审，最终将移到代码生成的那一刻。 当 AI 生成代码时同步完成安全检查，"写出不安全代码"这件事本身就可以被拦截，而不是等到后续环节发现再修复。这意味着安全能力需要嵌入代码生成工具本身，而不只是在流水线末端加一道扫描。

漏洞挖掘模型改变了攻防节奏

漏洞挖掘专用模型的关键影响，是把高水平漏洞研究从专家手艺变成可规模化的搜索过程。 Anthropic 在 Project Glasswing 中披露的 Claude Mythos Preview 已经能在真实开源软件中发现复杂漏洞，并将漏洞发现、利用构造、报告生成串成较完整的 Agent 工作流。模型开始具备持续阅读大型代码库、搭建测试环境、生成输入、验证崩溃、推导可利用性和形成报告的闭环能力。

漏洞挖掘的稀缺资源正在从"发现能力"转向"消化能力"。 过去企业担心的是发现不了问题，所以安全建设围绕扫描器、白盒工具、SRC 和红队演练展开。此类模型出现后，问题会逐渐变成发现结果太多、真假难辨、修复资源不足、披露节奏难以协调。

攻击侧获得的是低成本试错，防御侧承受的是高成本排队。 攻击者只需要找到一个可用入口，就可以围绕目标资产、组件版本和公开补丁差异持续尝试。防御方拿到同样的模型能力后，还要完成资产归属确认、影响面分析、兼容性测试、灰度发布、业务验收和应急沟通。发现速度越快，越会暴露组织内部修复链路的瓶颈。

N-day 风险会比 0-day 风险更早恶化。 公开补丁、提交记录、CVE 描述和测试用例会给模型提供足够多的线索，攻击者可以用模型把"已经公开但尚未普遍修复"的问题转化成更稳定的利用路径。企业如果仍然按传统节奏排期修复，就会在披露和部署之间留下更危险的窗口。

安全团队的应对重点应从"买一个 AI 扫描器"升级为"重构漏洞运营系统"。 真正决定风险下降速度的是组织能否把发现、定级、修复、验证和部署压缩成一个稳定流水线。防御方的优势在于拥有完整代码、架构、配置、日志和业务上下文，必须把这些内部信息变成模型可用的上下文，而不是只把模型当作外部黑盒扫描器。

AI 驱动网络攻击的系统工程分析、攻击链推理、十二类核心挑战与全链路实现，见 AI 驱动的全链路自动化网络攻击。

AI 攻防的时间常数转移

漏洞挖掘模型改变了攻防节奏（见上节），但更根本的转变是攻防双方的时间常数本身在被重新定义。

公开补丁成为攻击蓝本

公开补丁、提交记录、CVE 描述、回归测试用例——这些原本是为帮助防守方修复而发布的信息，同时给模型提供了完整的攻击线索。补丁一旦公开，就从防御工具变成了攻击教材。 模型可以系统化分析补丁差异，定位被修复的代码位置，反推漏洞触发路径，并生成可复现的 PoC。

这一变化意味着：

• "补丁已发布"不再等于"风险已降低"——它反而是攻击窗口的开始
• 传统依赖"披露-修复"时间差的安全运营节奏需要被重写
• 漏洞评级中"利用可能性较低"的标签需要重新校准——基于人类专家的评级可能低估了模型的利用能力

Patch gap 从月级压缩到小时级

N-day 风险的真正改变，是 patch gap 的时间常数发生量级转移：

• 传统节奏：补丁发布到攻击者产出可用 PoC，往往需要数周
• 现实节奏：能力足够的模型可以在几十分钟到几小时内完成同样的工作
• 单次利用的边际成本：API 调用成本从过去需要数月的研究投入，下降到只需数千美元
• 企业的补丁部署周期：通常仍以天或周计

"月级"和"周级"的传统补丁策略已经失效。 真实环境中的 patch gap——从补丁发布到大部分系统完成修复——往往比攻击者利用补丁生成 PoC 所需时间更长。模型能力越强，防守方能依赖的时间窗口越窄。

实证：从"实验室可能"到"已经发生"

这一变化已不再是理论预期，而是被多次实证：

• 安全研究团队使用前沿模型，在主流开源浏览器引擎的近期安全补丁上系统性复现漏洞生成，几小时内即可产出可触发崩溃的 PoC，并进一步构造完整的提权利用链
• 同一团队在闭源商业操作系统内核的 N-day 上复现了相同能力——从无源码、仅有补丁差异和反编译产物的环境出发，仍能产出从普通用户到系统权限的完整利用
• 独立研究团队在主流开源模型的智能体红队测试中，用几小时时间、不依赖人工编写的攻击代码，找到了远超传统人工红队产能的漏洞数量
• 行业研究系统映射了一年的 AI 驱动网络攻击，验证了既有攻击分类框架在 AI 时代仍然有效，但攻击密度与速度已发生质变
• 在受控的企业测试网络中，开源模型驱动下的智能体可以自主规划路径、传递载荷并实现类蠕虫式的横向传播——这说明从单点突破到多主机扩散的链路已可在模型主导下自动形成

这些实证共同指向一个结论：AI 时代，N-day 攻击的开发门槛已下降到与脚本小子利用现成 PoC 同等或更低的水平。 限制攻击者数量的不再是技术能力，而是 API 访问和成本。

防御侧的范式转移

当时间常数发生量级转移，防守方不能再用同一套节奏应对：

第一，补丁部署节奏要重写。 月度发布、多周分批上线、预发布到稳定版的滞后——这套节奏建立在"补丁武器化需要数周"的假设上，这个假设已经失效。月级发布周期需要压缩到周级甚至日级，关键组件的紧急更新需要脱离常规发布窗口独立推送。

第二，漏洞的工程修复要往前推。 补丁本身的响应速度有上限，但漏洞从出现到被利用的时间在缩短。根本性方案是减少漏洞本身的出现——内存安全语言迁移、编译时缓解措施（控制流保护、硬件影子栈）可以一次性消除整类攻击面，让攻击者在这类缓解存在时投入的工程价值归零。这是从"打补丁"转向"消灭漏洞类型"的范式转移。

第三，攻击面本身需要假设更可被快速利用。 工业控制系统、医疗设备、IoT 设备——这些维护窗口固定、固件锁定、可用性要求高的资产，在传统时间尺度下相对安全；在 N-hour 时代，它们会变得格外脆弱。需要专门为这些资产设计补丁通路、临时缓解和异常检测机制。

第四，红队和威胁情报的节奏要跟上。 内部红队、自动化红队平台、AI 红队 Agent 三层组合才能持续覆盖不断变化的攻击面。红队发现的价值要进入工程闭环——每个被验证的攻击样本都应自动转化为持久的回归测试用例和行为监控规则。

AI 时代的安全运营，本质上是和模型的学习速度赛跑。用月度节奏应对小时级威胁，再多的预算也无法补回时间差。

AI 红队

AI 红队真正要解决的问题，不是"找到多少 Jailbreak"，而是"发现 AI 从正确行为偏离到危险行为的最短路径"。 传统红队寻找系统被攻破的路径，目标是获取权限、窃取数据、控制系统。AI 红队寻找 AI 被操控的路径，目标是影响认知、影响决策、影响行为。因此 AI 红队本质上是在寻找"让 AI 偏离设计目标"的路径，这个定义让它覆盖四个层面，而不只是内容安全一个点。

AI 红队测试的对象不是孤立模型，而是模型、上下文、工具、权限、运行时和业务流程共同组成的 Agent 系统。单纯测试模型会不会输出违规内容，只能覆盖最表层风险；真正危险的场景往往发生在模型拥有工具能力、长期记忆和业务权限之后。红队需要验证 Agent 在真实约束下会不会读取不该读的数据、调用不该调用的工具、相信不该相信的上下文、执行不该执行的动作。

内容安全红队测试能否让模型输出不该输出的内容——Jailbreak、角色扮演绕过、编码绕过、多轮诱导——这是目前最成熟也最容易被过度聚焦的一层。认知安全红队测试能否让模型相信错误信息——Prompt Injection、RAG Poisoning、Memory Poisoning——验证 AI 会不会被骗。行为安全红队测试能否让 Agent 采取危险行为——删除文件、发邮件、转账、越权审批——验证 AI 会不会做错事，这是未来价值最高的方向。Agent 生态红队测试能否控制 MCP、Plugin、Workflow、Multi-Agent 生态链——验证一个 Agent 是否能污染另一个 Agent。

从系统层级看，AI 红队至少要覆盖四层。交互层测试输入输出、提示注入、越狱和敏感信息泄露；认知层测试推理、记忆、RAG、知识库和上下文污染；执行层测试工具调用、权限继承、沙箱逃逸和副作用控制；设施层测试云资源、网络隔离、凭证管理、CI/CD 和供应链。很多真实事故不会只有单一原因，而是多层防线同时出现缝隙后被串成完整攻击链。

对于高价值业务系统，红队目标应按风险分级而非攻击类型分类：导致资金损失和数据泄露是 P0，Agent 越权执行和敏感信息泄露是 P1，普通 Jailbreak 是 P2，无实际影响的绕过是 P3。这个分级直接决定修复优先级，而不是把所有攻击样本放在同等位置处理。

人工红队覆盖不了持续变化的 AI 系统，需要建立自动化红队平台。 模型每天都在变、Prompt 在变、RAG 在变、Agent 在变、MCP 在变——人工红队很快会失效。可落地的体系应是人工红队 + 自动化平台 + AI 红队 Agent 三层组合。

自动化红队的目标不应一开始就设定为完全替代高级专家。更现实的路径，是先把巡检、基础扫描、攻击样本变异、回归测试和高频行为链验证自动化，让专家把精力放在攻击面判断、业务影响评估和复杂链路设计上。高级专家负责定义攻击目标、筛选高价值路径、判断业务危害；自动化系统负责持续执行、扩展变体、记录证据和沉淀规则。

建设路径：首先建立攻击分类体系（先定义攻击树和攻击目标，否则测了上千个 Prompt 也不知道测了什么）；然后构建攻击样本库，来源包括 OWASP LLM Top 10、模型公司 System Card、漏洞平台和线上用户反馈，按攻击类型持续沉淀；核心是 AI 红队 Agent——让模型自动生成攻击变体、自动变异 Prompt、自动寻找绕过路径，一个攻击样本可以扩展出大量变体，本质上相当于 Prompt Fuzzer；再接入自动执行平台，每天定期对目标模型运行大量攻击样本，输出成功率、风险等级和趋势变化（某类攻击成功率突然上升，立刻触发告警）；评分依赖 Judge Model（LLM as a Judge）对输出做风险评分，因为"是否越狱"难以用规则判断。

Agent 行为测试是 AI 红队中最重要也最不成熟的部分。 当 Agent 拥有邮件、日历、代码仓库、MCP 等工具权限时，测试的不再是 Prompt，而是完整的行为链：能否发邮件给攻击者、能否删除文件、能否越权审批、能否访问他人数据。这需要在隔离环境中模拟 Agent 的完整执行链路，而不只是测试单条输出。

红队发现的价值要进入工程闭环。一次成功攻击不应只形成报告，还要转化为回归测试、行为监控规则、权限策略、工具网关规则和审计告警。否则红队只是阶段性证明系统会失败，没有让系统在同类失败上变得更难被攻破。

真实的高价值漏洞红队演练揭示了几个重要规律。2025 年 React Server Components 的 RCE 漏洞挑战中，116 名研究人员验证出 38 种独立的 WAF 绕过技术，包括递归 Unicode 编码绕过和基于打包工具特性的属性混淆——每一种都是静态规则无法提前枚举的。AI 在红队中的角色正在从"辅助"变成"主力"：模型被用于自动重现绕过路径，识别人工难以察觉的细微变体。更重要的工程原则是：每一个被验证的攻击样本都应自动转化为持久的回归测试用例，而不是修复后遗忘——这样红队发现的价值会从一次性事件变成持续保护的安全资产。单层防御在规模化红队攻击面前必然失守，WAF（请求层拦截）+ 运行时防御（执行层兜底）的双层架构是目前验证有效的模式：WAF 拦截绝大多数利用尝试，运行时层在代码执行阶段做最后兜底，两层配合才能在高强度攻击中保持稳健。

红队覆盖不了所有情况，生产环境必须同步建设行为监控——当线上出现"查询日历 → 读取通讯录 → 发邮件给外部地址"这类异常调用链时，自动触发告警。红队负责主动发现，监控负责被动兜底，二者结合才能形成完整的 AI 安全闭环。

防御侧的时间差问题

AI 在防御侧的核心价值是压缩响应时间，而不是提升检测精度。 漏洞从公开披露到被利用的时间已经被持续压缩，而企业的修复周期通常以月计。这个时间差是大多数攻击发生的空间。AI 驱动的自动修复、自动测试和自动影响面分析可以大幅压缩这个窗口，直接减小暴露风险。

但防御侧 AI 化的速度系统性慢于攻击侧。 攻击者采用新工具的门槛极低，廉价的暗网订阅就可以发动 AI 增强的攻击。防御侧需要把 AI 集成进现有安全基础设施、建立工作流、培训人员，这个周期以季度计。结构性的速度不对称不会因为防守侧也用了 AI 而消失。

安全大模型能力与风险的评测体系、八层评测框架、门禁分级与建设路径，见 安全大模型评测体系。

AI 安全认知飞轮

光收集信息源不够——大多数团队的真正问题不是缺信息，而是信息太多、看不过来、吸收不了、无法形成观点、无法影响决策。

长期来看，更值得研究的是一套认知飞轮：把外部信号持续转化为组织能力。

Signal：信号层

最底层是信号源：

• Anthropic Research、OpenAI Safety
• OWASP Agentic AI
• GitHub Trending、Hacker News
• arXiv
• AI 安全创业公司动态
• 真实攻击事件

绝大多数信息价值有限。真正重要的是弱信号——例如：

• Prompt Injection
• Tool Injection
• Memory Poisoning
• RAG Poisoning

单独看只是多个攻击技术，持续观察后会发现它们共同指向 Agent Security。高手关注的不是新闻本身，而是新闻背后的趋势。

Information：信息层

信号必须被结构化，否则很快遗忘。

例如发现一篇 Memory Poisoning 文章，提炼为：

类别：Memory Security
问题：长期记忆污染
攻击方式：伪造事实写入 Memory
影响：长期行为偏移
防御：验证、可信度评分、隔离

此时已经从文章变成结构化信息。

Knowledge：知识层

知识来自连接。

单独的 Prompt Injection、Tool Injection、Memory Poisoning 只是信息点。当它们被关联起来后：

Prompt + Memory + Tool → Agent Manipulation

开始形成知识体系。

不要收藏文章，要沉淀主题。 收藏品会过时，主题会持续生长。

Insight：洞察层

洞察是最稀缺的产物。

事实回答过去发生了什么，洞察回答未来可能发生什么。例如：

• Agent 安全未来比模型安全更重要
• Runtime 会成为新的安全边界
• AI 红队最终会演化为 Agent 红队

洞察本质上是预测能力。从已发生的多点信号中预判下一阶段的攻防焦点，是组织能力差异化的关键。

Decision：决策层

洞察不能影响决策，其价值就归零。

例如判断 Memory Security 未来重要，组织就可能：

• 建立专项研究
• 建立评测体系
• 建立防御机制
• 建立能力建设计划

此时洞察开始转化为行动。

Capability：能力层

最终目标是能力建设。

很多组织停在"知道风险"就结束。优秀组织会继续走完：

知道风险 → 研究风险 → 产品化 → 平台化 → 组织化

最终形成能力优势。

为什么它是飞轮

能力会反过来增强信号识别能力。研究越深入，越容易从海量信息中发现真正重要的弱信号。

Signal → Information → Knowledge → Insight → Decision → Capability → New Signal

不断加速循环。

长期来看，安全团队之间最大的差距不是技术水平，而是谁能够更快地把外部信号转化为组织能力。

飞轮落地要点

• 不要等所有信号都齐了再行动——单点信号不足时，先做局部研究
• 每个 insight 都要追问"会引发什么决策"——不能落地的洞察只是观点
• 能力建设以"可复用资产"为目标——平台化、流程化、文档化，而不是只挂在某个人脑子里
• 定期做飞轮体检——检查 signal 采集是否覆盖、knowledge 是否更新、capability 是否被使用

认知飞轮一旦建立，组织的学习速度会显著快于只靠个人努力的状态。