AI 与安全

AI 同时增强了攻击和防御能力，但这不是对称的竞争。 进攻只需要在无数次尝试中成功一次，防御需要每次都成功。AI 降低了发动攻击的成本和门槛，这对攻击侧的价值远大于对防御侧的价值。

信任的感知基础正在失效

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

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

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

攻击面从代码转向上下文

传统安全思维关注"恶意代码"——有没有可执行的攻击载荷。 AI Agent 带来了一个新的威胁模型：恶意内容不需要是可执行代码，只需要是能被模型当作指令解释的文字。

MCP 工具的安全问题是这种新威胁模型的清晰例子。已有记录的案例包括：在工具描述中嵌入不可见指令、通过 SQL 注入控制整个 Agent 工作流、通过文档中的隐藏提示让 Copilot 静默导出用户数据。这些攻击的载荷都是纯文字，通过正常的数据传输通道进入，不触发任何传统的恶意代码检测规则。

根本原因是 Agent 架构中"数据"和"指令"的边界不清晰。 Transformer 的注意力机制把系统提示、工具结果和用户输入都作为 token 序列平等处理，没有架构层面的机制区分"这是要处理的内容"和"这是要执行的命令"。这是当前 Agent 架构的结构性特征，靠打补丁无法解决。

供应链攻击的新形式

AI 模型仓库正在经历和 npm、PyPI 类似的供应链污染问题，但规模更难控制。 Hugging Face 上恶意模型数量年增长 6.5 倍，攻击手法包括在模型文件中嵌入恶意代码、注册被删除的热门用户名上传污染版本。

但模型供应链攻击比软件包供应链攻击更隐蔽。恶意软件包的检测相对成熟，有成熟的扫描工具和签名机制。模型后门则不同：研究表明极少量的训练数据污染就可以植入后门——在标准评估中表现完全正常，但在特定触发条件下持续输出有害内容。你无法通过"运行测试"来可靠地检测模型行为是否被植入了后门，因为后门被设计成只在特定条件下触发。

对工程师的实际影响： 使用第三方预训练模型，尤其是经过微调的领域模型，需要像对待第三方代码库一样进行供应链审计，而不是默认信任仓库的存在。"在 Hugging Face 上有很多 Star"不是安全保证。

代码安全审计的能力边界

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

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

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

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

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

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

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

漏洞挖掘的稀缺资源正在从“发现能力”转向“消化能力”。 过去企业担心的是发现不了问题，所以安全建设围绕扫描器、白盒工具、SRC 和红队演练展开。Mythos 级模型出现后，问题会逐渐变成发现结果太多、真假难辨、修复资源不足、披露节奏难以协调。Anthropic 后续的 Glasswing 更新 也指向同一个结论：AI 可以快速产生大量漏洞线索，但补丁验证、维护者响应、用户升级和风险缓释仍然很慢。

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

N-day 风险会比 0-day 风险更早恶化。 真正昂贵的 0-day 研究仍然需要模型能力、计算资源、目标环境和验证体系，但公开补丁、提交记录、Issue、CVE 描述和测试用例会给模型提供足够多的线索。攻击者可以用模型把“已经公开但尚未普遍修复”的问题转化成更稳定的利用路径。企业如果仍然按传统节奏排期修复，就会在披露和部署之间留下更危险的窗口。

安全团队的应对重点应从“买一个 AI 扫描器”升级为“重构漏洞运营系统”。 需要优先做好资产和组件清单、外部暴露面收敛、关键系统快速补丁通道、自动化回归测试、可灰度回滚的发布机制、运行时隔离和最小权限。AI 漏洞挖掘工具可以提高发现效率，但真正决定风险下降速度的是组织能否把发现、定级、修复、验证和部署压缩成一个稳定流水线。

企业内部也要把模型用于防御前移。 最有价值的使用位置在设计评审、依赖引入、代码合并和发布准入阶段，让高风险路径提前暴露。对核心系统，应建立可重复的安全评测 Harness，让模型围绕真实威胁模型持续生成测试、审计变更和复核修复。防御方的优势在于拥有完整代码、架构、配置、日志和业务上下文，必须把这些内部信息变成模型可用的上下文，而不是只把模型当作外部黑盒扫描器。

模型能力越强，越需要安全隔离和使用治理。 漏洞挖掘模型天然具备双重用途，不能让它直接连接生产资产、敏感代码库和外部网络。企业内部使用时应采用隔离环境、只读凭证、任务级授权、完整审计、输出脱敏和人工复核；对可生成利用链、绕过手法或批量扫描脚本的任务，应进入更严格的审批和留痕流程。模型本身不是安全边界，围绕模型的执行环境和操作流程才是安全边界。

Agent 运行安全：权限最小化的真正含义

最小权限原则不是新概念，但在 Agent 环境里它有更紧迫的意义。 传统系统里，权限决定了"这个用户能做什么"。Agent 环境里，权限决定了"被注入的攻击者通过这个 Agent 能做什么"。Agent 的权限边界直接定义了攻击的爆炸半径。

一个可以读取文件系统和发送邮件的 Agent，一旦被提示注入攻击，攻击者就可以通过它读取 ~/.ssh/ 下的密钥再发给自己——不需要直接攻破系统，只需要攻破 Agent 的上下文判断。

实践原则：只读优先于读写，本地工具优先于外部 API，可逆操作优先于不可逆，高风险操作前强制人工确认。密钥通过切面注入网络请求 Header，不直接暴露给 Agent 可生成或访问的代码环境。

防御侧的时间差问题

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

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