本文从防御与认知教育的角度，梳理 AI 系统区别于传统系统的安全图景。文中所有内容聚焦攻击面认知、风险框架与业务影响，不提供可直接运行的攻击代码或入侵步骤。正如安全圈那句老话：你只有知道攻击长什么样，才能写出有效的检测规则。
开篇：一面「光滑的墙」
设想一个做了五年传统渗透测试的安全工程师，某天接到一个新任务：「这是我们公司的 AI 客服机器人，帮我们做个红队评估。」
他打开 Burp，所有流量都是干干净净的 HTTPS JSON。扫端口，只看到 443。fuzz 参数，所有输入都返回正常的 200。从外部看，这个系统像一面光滑的墙——没有缝。
但他心里清楚有问题。这个客服机器人能调用内部工具，能查数据库，能根据用户的提问临时决定下一步动作。它的「业务逻辑」不写在代码里，而写在一段对外不可见的系统提示词里。它的「决策权」不归任何一个传统的 RBAC 系统管，而是大模型自己根据上下文推理出来的。
他感觉得到攻击面在那里，但传统工具找不到入口。
这正是 AI 安全要解决的核心困境：我们面对的，是一类根本不同的安全目标。
这篇文章不教你怎么攻击，而是带你看清——为什么 AI 系统的安全逻辑，和你熟悉的那一套完全不一样。理解这一点，无论你是开发者、企业管理者还是安全从业者，都至关重要。
一、钱在往哪儿涌：AI 已经从工具变成基础设施
要理解为什么 AI 安全突然变得紧迫，先看几个数字。
斯坦福 HAI 在 2025 年的《AI 指数报告》里给出：
| 指标 | 数值 |
|---|---|
| 2024 年美国私人 AI 投资 | 1091 亿美元 |
| 全球生成式 AI 投资 | 339 亿美元 |
| 基础模型在软件工程任务上的能力 | 每七个月翻一番（METR 研究） |
如果只看金融指标，这意味着 AI 已经从研究领域进入企业生产线。再看实际比例：
- 微软 CEO Satya Nadella 公开承认，微软 20-30% 的代码由 AI 生成
- Google CEO Sundar Pichai 说，Google 超过 1/4 的新代码是 AI 写的
- 微软 CTO Kevin Scott 预测，五年后 95% 的代码将由 AI 写
这里有个容易被忽视的事实：即使你的公司宣称「我们不用 AI」，那也只是表象。 你用的开源库、SaaS 产品、第三方组件，里面都已经塞满了 AI 生成的代码。
AI 已经从工具变成了基础设施。
这件事对安全从业者是双刃剑。一面，AI 是防御工具——告警分类更快、异常检测更准、恶意软件分析更自动化。另一面，AI 自己变成了高价值攻击目标，而且攻击面是全新的。如果防御方不在现在就把 AI 系统的攻击面搞清楚，攻击方会比我们跑得快。
二、「红队」这个词，已经悄悄变了
在大模型时代，连「红队评估」的内涵都发生了变化。
传统红队评估的是确定性系统——一个 SQL 注入要么成功要么失败，一个权限提升要么拿到 root 要么拿不到。所有结果都是离散的，有客观判定。
AI 红队要谈的词，变成了：可信性、伦理、价值观、公平性、安全性。这些词单看每一个都不是技术词，但它们都是 AI 安全的合法测试范畴。这是一次范式转移。
「负责任 AI」（Responsible AI）给安全评估定义了几个全新的风险类别：
| 风险类别 | 要回答的问题 |
|---|---|
| 公平性 | 模型在带偏见的数据上训练后，会不会做出歧视性决策？比如对某些族群系统性拒贷？ |
| 安全性 | 模型能不能被诱导生成虚假信息、极端内容，或协助网络攻击？ |
| 隐私 | 模型能不能被诱导泄露训练数据中的敏感信息？是否符合 GDPR、个人信息保护法？ |
| 透明度 | 模型决策能不能被解释？还是只是事后编出来的说辞？ |
这里的麻烦在于：传统漏洞是布尔型——要么有要么没有。AI 风险大多是光谱型。
一个大模型可能「略微」以误导性方式回答问题，但又不到「产生明显假信息」的程度。一个回答里 5% 的偏见和 50% 的偏见之间，边界是模糊的。这就要求评估者具备跨学科素养——不光是安全技术，还得懂一点伦理学、社会学，甚至哲学。
三、三个根本性变化：我们攻击的不再是文件，而是行为
如果用一句话总结 AI 安全和传统安全的区别，那就是：威胁的对象，从「文件」变成了「行为」。 展开来说，有三个根本性的变化。
变化一：价值从文件迁移到行为
传统攻击者偷文件、偷数据库、偷凭据。AI 时代，价值还在不在文件里？在，但不全在。
- 模型本身的权重是高价值资产
- 模型的输出和决策是高价值资产
- 模型的训练数据偏好是高价值资产
让模型泄漏 embedding、让模型背出训练里的某个片段、操纵模型的回答把客户引向错误的金融决策——这些都是窃取价值，但都不是窃取文件。传统的 DLP（数据防泄漏）盯着文件流动，却拦不住这类「行为级」的价值流失。
变化二：持久化机制变成动态的
传统持久化靠磁盘——后门、计划任务、Rootkit、Webshell。容器重启一下，大半都没了。
AI 系统的持久化在哪里？
在投毒过的数据集里、在向量数据库的某条 entry 里、在 Agent 的长期记忆里。
这些东西会跨容器重启存活，会传播到新部署，会影响未来的输出。一个被污染的训练数据集，即使你换了一代模型、做了微调，污染依然可能残留。你重启服务器解决不了它，因为它根本不在进程里。
变化三：系统会自主行动
这是最关键、也最容易被低估的一点。
Agent 调用工具、开工单、发邮件、触发云上动作。如果攻击者能影响一个 Agent，他不需要手动操作每一步——Agent 会自动把恶意指令扩展成成千上万个动作。
Anthropic 在关于 MCP 代码执行风险的报告里展示过这种放大效应：一个被注入的提示词，可以演化成数千个恶意操作。
把这三件事合起来，传统安全的防护目标（防止进系统、防止立持久化、防止控制基础设施）就不够了。AI 安全要防的，变成了：操纵决策、影响数据、自动化攻击规模。
四、为什么董事会该担心：把漏洞翻译成业务影响
安全报告最终写给谁看？是写给 CEO、CFO、合规官看的。技术细节他们看不懂，但业务影响他们看得懂。
这里有几个让管理层睡不着的数字：
- Gartner 预测：到 2027 年，40% 的 AI 相关数据泄露将来自跨境生成式 AI 滥用。
- IBM 2025 年数据泄露成本报告：全球平均泄露成本是 444 万美元，16% 的泄露事件已经涉及攻击者使用 AI 工具。
一条真实感很强的业务影响链
想象一个 Agent 负责审批费用报销。
传统攻击者要伪造 PO、报表、签字——成本高，速度慢。在 AI 系统里，攻击者只需要让那个 Agent 自动批准伪造交易就行。一段记忆污染，可以在被发现之前批掉几千笔欺诈交易。损失是直接的、可量化的，而且随自动化扩张。
监管违规会进一步放大伤害。一份被污染的合同文档进入 RAG 系统，模型在回答合规问题时引用了被改过的条款，产生了违规建议。在金融、医疗、能源这些受监管行业，哪怕只是一次输出错误——泄漏了患者数据，或批准了未授权的交易——都可能引发监管调查，赔偿金额几百万起步。
更糟的是，这种风险不光来自恶意攻击，合法用户也可能无意中触发。已经有医疗工作者通过生成式 AI 工具不小心泄露受保护数据的案例。
声誉损害则更深远。特斯拉的自动驾驶事故就是反复出现的样本：一系列致命事故触发 NHTSA 调查，导致召回数百万辆车，持续的媒体报道侵蚀公众信任，影响蔓延到整个行业。2026 年 3 月，NHTSA 把对特斯拉 FSD 的调查升级为「工程分析」——这件事直接拖累了股价。AI 系统的失败，有直接的金融影响。
六问清单：把技术发现翻译成业务语言
每次完成 AI 安全评估，可以用这六个问题来组织影响陈述：
| # | 问题 | 意义 |
|---|---|---|
| 1 | 这个系统在做什么决策？ | 自动审批、内容审核、医疗建议、信用评估…… |
| 2 | 谁/什么消费它的输出？ | 终端用户、下游系统、合规报告、外部客户…… |
| 3 | 下游每天发生多少笔交易？ | 决定攻击规模化的潜在体量 |
| 4 | 被操纵的潜在金融影响是多少？ | 单笔损失 × 频率 |
| 5 | 适用哪些监管框架？ | GDPR / HIPAA / SOX / PCI-DSS / 个人信息保护法 / 数据安全法 |
| 6 | 修复需要多久？ | 模型重训练比打补丁慢得多，这是关键差异 |
举个例子，把「RAG 摄入未经验证」翻译成业务陈述：
攻击者可向法律文档检索系统注入虚假合同条款，可能导致监管违规，产生 50 万元罚款，并需要 3 个月的法律审查。
董事会能听懂这种话。他们会基于这种陈述去分配预算，去定修复优先级。这就是安全评估的最终落点——不是发现漏洞，而是把漏洞翻译成业务影响。
五、三个必须熟悉的框架：给 AI 安全一套共同语言
随着 AI 大规模商用，业界出现了三个相互补充的安全框架。每个框架解决一个不同的问题，合起来才构成完整方法论。
MITRE ATLAS：战术分类
ATLAS（Adversarial Threat Landscape for Artificial-Intelligence Systems，AI 系统对抗性威胁图谱）是 MITRE 把著名的 ATT&CK 思路扩展到机器学习领域的产物。它把攻击技术按战术阶段分类——训练阶段、推理阶段、部署阶段。
它的价值是提供统一标签语言。写报告时把发现归类到具体的 ATLAS 技术 ID（例如 AML.T0051 - LLM Prompt Injection），开发团队和管理层就能立刻查到对应的描述和缓解方案。
OWASP Top 10 for LLM：应用层风险清单
OWASP 把传统的 Web 应用 Top 10 思路套用到大模型应用上，产出了 LLM 专属的 Top 10：
提示词注入、不安全的输出处理、训练数据污染、模型 DoS、供应链漏洞、敏感信息泄漏、不安全的插件设计、过度代理权限、过度依赖、模型窃取。
它的价值在于面向开发者，每条风险都给出了代码层级或运行时策略层级的缓解。如果你在做 AI 应用的安全评审，OWASP LLM Top 10 是最佳起点。
NVIDIA AI Kill Chain：攻击者生命周期
NVIDIA 提出的 AI Kill Chain 把攻击者活动顺序化：
这个链条的好处是告诉防御方：在哪些环节最能有效中断攻击。
| 阶段 | 防御方的着力点 |
|---|---|
| 侦察 | 加固 HTTP 元数据、移除暴露内部架构的响应头 |
| 投毒 | 加摄入校验、签名验证、来源溯源 |
| 劫持 | 输入消毒、模板隔离、护栏规则 |
| 持久化 | 向量库完整性校验、记忆 TTL、定期清理 |
| 影响 | 输出过滤、行动审批、人在回路 |
三框架怎么配合
简单总结：
- ATLAS 提供共享词汇——报告里所有名词都来自 ATLAS，跨团队对齐。
- OWASP 提供应用层测试目标——按列表做检查，不会漏掉常见类别。
- NVIDIA Kill Chain 提供时间序列——按链条组织防御活动。
结语：理解 AI 安全，先理解它「不一样」在哪
用一段话总结这篇文章：
AI 系统是一类全新的安全目标。它的价值在于行为而非文件，持久化在于数据而非进程，影响通过自主行动而非人手扩展。
防护它需要新的方法论，这套方法论由 MITRE ATLAS（战术分类）、OWASP LLM Top 10（应用层风险）、NVIDIA AI Kill Chain（时间序列）三个框架共同构成。而安全团队的工作，不只是找漏洞，更是把技术发现翻译成业务影响，让决策层愿意为修复买单。
如果你正在构建或运营任何接入了大模型的系统，这篇文章想传递的核心只有一句：别用看待传统系统的眼光看待 AI 系统。那面看起来「光滑的墙」上，缝隙的位置和你想的完全不同。
声明：本文基于公开的 AI 安全教育材料整理，立场为防御与风险认知。所有内容不涉及可执行的攻击手法，旨在帮助开发者和企业建立对 AI 系统安全的正确认知。如需深入实践，请在合法授权的测试环境中进行。
