夜雨聆风AI 的安全现在发展的怎么样了？花时间进行了调研，如果你没有时间或者耐心看大长段的内容，我快速总结下：
AI 安全是 AI 能否进入真实业务和真实生活的前置条件。所以 AI 安全问题必须提前解决，但目前 AI 的能力扩张速度，已经超过了安全边界建设速度。 AI 安全正在从内容治理，变成执行治理。所以目前重点需要解决的问题是：合法动作产生的非法后果。 AI 安全目前的整体状态是，模型侧开始成熟，系统侧还在补课，执行侧刚刚暴露。
以下是正文。
目前很多人看待 AI 安全时的第一反应是：“小孩儿还没开始学习跑，就担心他会摔倒。”这个判断背后有一套很常见的产业逻辑：先发展，再治理。先把规模做起来，先把效率跑出来，先让行业形成基本形态，等问题暴露到一定程度，再补安全、补监管、补标准、补工程规范。
但这套逻辑有一个隐含前提：后补治理的成本是可承受的。
现实往往不是这样。矿山安全、环境治理、食品安全，都反复证明过一件事：很多安全问题不是不能治理，而是越晚治理，治理成本越高。等粗放体系形成产业惯性，后面再想改，就不再是加几条规则、开几次专项行动、上线几套监管系统可以解决的问题。
AI 更麻烦。它不是一个单纯的新工具，也不是一个只在屏幕里输出内容的软件功能。AI 正在进入办公系统、研发流程、数据平台、客服系统、审批流程、安全运营和云资源管理。它不只是回答问题，而是在逐步获得理解、规划、调用工具和执行任务的能力。
所以对 AI 安全的基本判断是：AI 安全不是发展之后的修补项，而是 AI 能否进入真实业务和真实生活的前置条件。《谷歌云 AI 基础设施现状》调研报告里，安全风险被列为组织采用生成式 AI 时最主要的挑战之一。这说明一个现实问题：AI 安全已经不是安全团队的内部议题，而是在直接影响企业是否敢把 AI 接进真实业务。
现在 AI 安全的发展状态，可以概括成一句话：模型安全已经开始体系化，应用安全正在补工程欠账，Agent 安全刚刚进入真正的风险暴露期。
但仅仅这样说还不够，因为 AI 安全有一个经常被混在一起的问题：个人 AI 安全和企业 AI 安全不是一回事。
企业 Agent 更像运行在受控环境里的数字员工。它可以有独立身份、专用账号、受控网络、沙箱环境、统一日志、审批流程和集中治理平台。个人 Agent 更像跑在用户电脑上的本地助理。它要操作用户真实浏览器、真实邮箱、真实文件、真实登录态。它如果完全脱离这些真实环境，能力就会大幅下降。
所以企业 AI 安全的核心是隔离和治理，个人 AI 安全的核心是监督和边界确认。
这两个问题不能用同一套答案解决。
一、从 AI 的发展看 AI 安全
AI 安全的变化，基本跟 AI 产品形态的变化同步。
最早的时候，大家讨论的是模型本身。模型会不会幻觉，能不能越狱，会不会输出有害内容，会不会泄露训练数据。这一阶段的安全重点，是让模型不要乱说。安全微调、内容过滤、拒答策略、系统提示词、红队测试，都是围绕这个目标展开的。
后来，大模型开始进入应用层。企业把模型接到知识库、客服系统、代码助手、数据分析平台和办公流程里。风险不再只来自模型输出，而来自模型接触了什么数据、检索了什么文档、调用了什么接口、把什么内容写进了日志。
到了这个阶段，安全问题已经从“输出是否安全”扩展到“应用链路是否安全”。
再往后，就是 Agent。Agent 和 Chatbot 最大的区别，不是它更聪明，而是它开始有手有脚。它可以读文件、调接口、写代码、发邮件、改配置、跑命令、查数据库，也可以在多步任务里连续规划和执行。
这时，AI 安全的性质发生了变化：Chatbot 的风险是说错话。Agent 的风险是做错事。
说错话影响的是认知，做错事影响的是系统。一个错误回答可能误导用户，一个错误执行可能直接进入业务流程、数据资产和生产环境。
这也是现在 AI 安全讨论里最重要的变化：AI 安全正在从内容治理，变成执行治理。
过去的核心问题是“模型输出是否安全”。现在的核心问题是“AI 执行是否可控”。
二、AI 安全现在的真实状态
如果按成熟度看，现在 AI 安全是三层断裂的状态。
模型侧已经有框架。模型厂商在做安全微调、红队测试、危险能力评估和发布前审核。OWASP 已经把 LLM 应用风险和 Agentic AI 风险单独拆出来。NIST、EU AI Act、ISO/IEC 42001，以及国内关于生成式 AI、算法备案、数据安全和个人信息保护的规则，也都在把 AI 拉进治理框架。
应用侧还在补工程债。大量企业已经把模型接到知识库、数据库、工单系统和内部 API，但工程安全体系还没有完全跟上。从模型厂商的发布材料看，安全框架已经很完整；从企业内部的实际使用看，很多 AI 应用还停留在“业务部门自己接 API、自己建知识库、自己写提示词”的状态。模型侧看起来很先进，应用侧和执行侧却经常是野生生长。
Agent 执行侧刚开始暴露真实风险。真正具备工具调用、连续决策和业务执行能力的 Agent，才刚进入规模化落地阶段。很多个人 Agent 也已经开始操作浏览器、邮箱、文件系统和本地应用，但用户对它们实际做了什么并不总是清楚。它读取了哪个页面，点击了哪个按钮，复制了什么内容，是否准备发送邮件、上传附件、修改配置，这些行为如果没有运行时监督，就很难被用户及时发现。
所以现在真正的问题是：AI 的能力扩张速度，已经超过了安全边界建设速度。
三、AI 安全要重写的五层能力
现在理解 AI 安全，不能再把它看成几个零散问题。
更合理的方式，是把它看成一套分层架构。它至少包括五层：模型安全、应用安全、Agent 执行安全、工具链与供应链安全、治理与运营安全。
这五层不是平铺的功能清单，而是一条能力扩张链路。
模型安全解决“AI 会不会乱说”。应用安全解决“AI 接入数据和系统后会不会泄露、越权、被注入”。Agent 执行安全解决“AI 拿到工具和权限后会不会做错事”。工具链与供应链安全解决“AI 调用的外部能力是否可信”。治理与运营安全解决“企业和个人能不能长期管理、审计、阻断和回滚”。
这套架构基本定义了 AI 系统的安全边界。
过去，安全边界主要围绕网络、主机、账号、应用和数据展开。AI 出现之后，边界开始扩展到上下文、提示词、RAG 检索结果、工具描述、Agent 记忆、任务规划和模型行为。这些东西在传统软件里不是核心安全对象，但在 AI 系统里都可能变成攻击面。
1. 模型安全：从输出审核到能力边界
模型安全是最早被关注的一层。
早期大家关心的是模型会不会输出违规内容，所以安全手段也比较直接：安全微调、内容过滤、拒答策略、系统提示词、人工红队。这些工作有价值，但它们主要解决的是输出层问题。
现在模型安全正在往能力边界管理发展。
前沿模型不仅要评估有害内容输出，还要评估网络安全能力、生物安全能力、欺骗能力、自主规划能力、工具使用能力，以及在多轮任务里是否会表现出更高风险的行为。
这个变化很重要，因为更强的模型不一定天然更安全。更强的模型更会理解任务，也更会规划步骤；如果目标被污染，或者工具权限设计错误，它也可能更完整地把错误目标执行到底。
所以模型安全的核心问题，已经不是“模型能不能拒绝某些问题”，而是“模型在什么条件下具备什么能力，这些能力能不能被评估、限制和解释”。
这里有四个建设点。
第一，建立模型能力评估基线。不能只测通用问答能力，还要测网络安全、生物安全、隐私泄露、越狱抵抗、多轮诱导、工具调用和危险指令遵循能力。
第二，建立发布前安全门槛。某些能力一旦超过阈值，就不能只靠提示词约束，而要进入更严格的访问控制、速率限制、审计和人工审批。
第三，把模型评测放到业务场景里。单轮问答安全，不代表接入知识库、代码仓库、数据库之后仍然安全。模型评测必须从静态测试走向场景测试。
第四，保留模型行为证据。安全评估不能只输出一个分数，还要保留测试样本、触发条件、拒答逻辑、失败案例和复盘结论。否则后面无法解释模型为什么在某个场景里失效。
模型安全是底座，但不能替代系统安全。
同一个模型，单独聊天时风险有限；接上数据库、浏览器、代码仓库和企业邮箱之后，风险会完全变化。模型评测只能证明模型在某些测试条件下的表现，不能覆盖真实业务里的所有组合。
模型安全解决的是“脑子”问题，不解决“手脚”问题。
2. 应用安全：问题经常出在接法上
大多数企业不会训练基础模型，而是把模型接进自己的业务系统。
这就是 AI 应用安全的主战场。
典型场景包括内部知识库、智能客服、合同审查、数据分析、代码助手、办公助手和安全运营助手。这里的风险，往往不是模型本身坏了，而是模型和企业系统之间的连接方式有问题。
知识库没有做权限过滤，普通员工可能问出管理层文档。RAG 没有做数据来源校验，外部文档里的恶意指令可能进入上下文。日志没有脱敏，用户输入的敏感信息可能留在平台里。API 没有最小权限，模型可能调用超出当前任务需要的接口。
Prompt Injection 是应用安全里最典型的问题。
它麻烦的地方在于，攻击入口不一定来自用户输入。网页、邮件、PDF、Issue、代码注释、工具返回值，都可能携带隐藏指令。模型会把这些内容当成语义理解，而不是像传统程序那样把它们视为普通数据。
这也是 AI 应用和传统应用的差异。
传统应用处理的是数据。AI 应用处理的是语义。数据可以过滤，语义会被理解。一旦不可信内容和高权限工具进入同一个上下文，风险就会变得很难控制。
所以应用安全不能只靠提示词。
提示词是软约束，不是硬边界。真正有效的安全设计，应该放在权限、数据、上下文、工具调用和日志审计里。
如果从工程侧看，AI 应用安全要补五类能力。
第一，RAG 权限过滤。知识库不是把文档切片、向量化、塞进向量库就结束了。每一次检索都应该带着用户身份、组织关系、数据标签和访问策略执行。否则模型没有越权，检索系统却已经把越权内容取出来了。
第二，不可信上下文隔离。来自网页、邮件、外部文档、Issue、插件返回值的内容，都应该被标记为不可信输入。模型可以阅读这些内容，但不能让这些内容覆盖系统指令、修改任务目标或者直接触发高权限工具。
第三，敏感信息治理。输入、输出、日志、缓存、向量库、训练回流、第三方 API 调用，都可能成为泄露点。AI 应用的数据链路比传统应用更长，DLP 不能只盯最终回答，还要覆盖上下文和工具调用过程。
第四，API 最小权限。AI 应用调用业务系统时，不应该使用一个万能服务账号。不同场景、不同用户、不同任务应该对应不同权限，尤其是写入、删除、导出、审批这类动作，必须单独管控。
第五，应用级红队。传统渗透测试更关注接口、参数、鉴权和漏洞。AI 应用红队还要测提示注入、间接注入、RAG 投毒、越权检索、工具误调用、敏感信息外泄和多轮诱导。
应用安全的核心，是把 AI 应用重新纳入软件安全工程，而不是把它当成一个会说话的页面组件。
3. Agent 执行安全：从权限隔离到行为监督
Agent 安全是现在 AI 安全里最值得关注的一层，因为 Agent 让 AI 从“生成系统”变成了“执行主体”。
传统安全关注非法访问，典型链路是绕过认证、利用漏洞、提权、执行恶意代码。Agent 风险不完全一样，它更常见的问题是：合法动作产生非法后果。很多时候，Agent 没有绕过权限，也没有利用漏洞，只是用正常身份、正常工具和正常流程，执行了一个错误目标。
办公 Agent 被邮件里的隐藏指令诱导，修改了审批金额。代码 Agent 读取外部 README 后，执行了攻击者写在文档里的命令。安全运营 Agent 误判业务流量，自动封禁了核心业务服务器。知识库 Agent 按照用户提示，检索并返回了不该返回的内部文档。
这些问题最麻烦的地方在于，传统安全系统未必会报警。日志上看，账号合法，接口正常，权限没有突破；真正出问题的是目标理解、上下文污染和自动执行之间的组合。
所以 Agent 安全不能只问“有没有越权”，而要问：Agent 代表谁执行，能调用什么工具，能访问什么数据，实际做了什么动作，出了问题能不能阻断和回滚。
从这个角度看，Agent 执行安全不是命令拦截问题，而是动作语义安全问题。同样是“导出数据”，有的场景是正常报表，有的场景是数据泄露；同样是“发送邮件”，有的场景是正常通知，有的场景是外发敏感附件；同样是“封禁 IP”，有的场景是自动处置攻击，有的场景是误封业务网关。真正要判断的不是动作本身是否危险，而是这个动作在当前任务、当前身份、当前数据、当前上下文里是否应该发生。
这里需要区分企业 Agent 和个人 Agent。
企业 Agent 通常运行在企业可控环境里，比如服务器、云平台、受控终端、安全运营平台、运维平台。它们接入的系统、使用的账号、调用的 API、访问的数据范围，都可以提前设计。因此企业 Agent 的安全重点是隔离和治理：独立身份、最小权限、任务级授权、策略引擎、沙箱执行、全链路审计。
个人 Agent 不一样。它往往跑在用户电脑上，使用用户真实账号、真实文件、真实浏览器和真实应用环境。如果强制使用沙盒浏览器，登录态没了，很多场景也就不可用了。因此个人 Agent 的安全重点不是隔离，而是监督和边界确认。
个人 Agent 也不能简单按“浏览器 Agent”“邮箱 Agent”分类。现实里它通常是混合执行：能走 API 的地方走 API，API 覆盖不到、语义不完整、权限流程复杂、需要网页上下文的地方，就会退回到 UI 操作。
API 通道相对好管，因为接口、参数、权限模型、返回结构和审计记录都比较明确。它的重点是 OAuth scope、token 权限、调用参数、数据标签和调用日志。
UI 通道更难。点击“发送”本身不危险，危险的是发给谁、发了什么、为什么要发、用户原始任务有没有要求外发。点击“提交”本身也不危险，危险的是提交到哪个系统、修改了什么字段、影响哪个流程、是否可回滚。UI Agent 的安全重点不是监控每一次点击，而是理解关键动作的语义和边界。
所以个人 Agent 更合理的安全模型是：真实环境 + 运行时监督 + 边界确认。
低风险动作自动执行，比如阅读网页、总结邮件、生成草稿、读取当前项目文件、运行本地测试。高风险动作必须解释后确认，比如发送邮件、上传文件、外发附件、删除数据、支付下单、授权第三方、修改安全设置、提交审批、修改生产配置。
确认框也不能只写“是否允许发送邮件”。它应该告诉用户：Agent 准备发给谁，是否外部域名，附件包含什么，是否有敏感信息，用户原始任务是否要求外发，这个动作能不能撤回。
对这类不可逆或外发类动作，可以采用“草稿优先”的产品原则。邮箱默认生成草稿而不是直接发送；代码 Agent 默认提交 PR 而不是直接合并；办公 Agent 默认生成审批草稿而不是直接提交；网盘 Agent 默认生成整理计划而不是直接批量删除。
所以这一层可以总结成一句话：企业 Agent 的安全重点是隔离，个人 Agent 的安全重点是监督；API Agent 管权限和参数，UI Agent 管语义和边界。
Agent 执行安全的目标，不是阻止 Agent 做事，而是让它每一次关键动作都能回答三个问题：为什么要做，会影响什么，能不能撤回。回答不了，就不应该允许它自动执行。
4. 工具链与供应链安全：自然语言也会成为攻击面
Agent 的能力来自工具。
Skill、MCP、插件、浏览器、命令行、数据库、云平台 API，都是 Agent 的外部能力来源。工具越多，Agent 越有用；工具越多，攻击面也越大。
传统供应链安全关注依赖包、镜像、脚本和二进制文件。Agent 时代还要关注自然语言。
工具描述、参数说明、README、网页内容、返回值，过去只是给人看的说明文档；现在它们会被模型读取，并参与模型决策。攻击者可以把恶意指令写进工具描述里，让模型误判工具用途；也可以污染工具返回值，让 Agent 继续执行错误步骤。
以前我们担心代码里有后门。现在还要担心自然语言描述里有后门。
这就是 Agent 时代供应链安全的新变化。
Skill 和 MCP 不能按普通插件管理。企业需要建立工具准入机制，包括静态分析、动态沙箱、权限声明、调用审计、版本复测、行为监控和黑白名单。
这里的重点不是“禁止工具”。
没有工具，Agent 就失去价值。真正要做的是把工具分级，把调用管住，把返回值校验起来。
工具链治理要做四件事。
第一，工具准入。所有进入企业 Agent 环境的 Skill、MCP 服务、插件和外部 API，都要有来源、版本、权限声明、依赖清单和维护责任人。
第二，工具描述审查。传统扫描器能发现恶意代码，却很难发现自然语言里的恶意意图。工具描述、参数说明和返回值样例，都应该进入语义安全检测范围。
第三，工具权限收敛。一个发邮件工具不应该顺手拥有读取全量通讯录、访问全部附件、调用外部网络的能力。工具能力要拆小，权限要按任务授予。
第四，运行时监控。静态安全不够，因为工具可能前期表现正常，后期在特定条件下触发恶意行为。运行时要看外联、文件访问、敏感数据读取、异常返回值和调用频率变化。
工具链安全的本质，是给 Agent 的“手和脚”做安全治理。
5. 治理与运营安全：AI 安全不是一次性评审
AI 应用不是上线一次就结束。
它的风险会随着模型版本、提示词、知识库内容、工具列表、业务流程和用户行为持续变化。今天安全的系统，明天接了一个新 MCP 服务，风险就可能完全不同。
所以 AI 安全最终一定会进入治理和运营层。
上线前，要做场景分级、数据分级、模型评测、Prompt Injection 测试、工具准入和红队测试。运行中，要做行为审计、权限控制、意图检测、沙箱隔离或运行时监督、人机确认、异常外联监控和敏感数据检测。出事时，要能熔断、回滚、溯源、复盘。复盘后，要把样本回灌到检测规则、红队用例、策略引擎和安全基线里。
这里不能只停留在制度层。企业需要一套可运行的 AI 安全治理机制。
第一，建立 AI 资产台账。企业必须知道自己内部有哪些模型服务、RAG 应用、Agent、MCP 服务、Skill、插件、API Key、向量库和知识库。没有资产台账，后面所有治理都是空的。
第二，建立场景风险分级。只读问答、内部辅助、业务写入、高权限执行、生产处置，不能用同一套安全要求。越接近核心业务，越要降低自主程度，提高审批强度。
第三，建立 AER 类风险评分。可以按权限范围、工具能力、数据敏感度、自主程度、可逆性来评估 Agent 风险。分数不需要特别精确，但必须能指导治理强度。
第四，建立 AI 红队用例库。红队不能每次从零开始。提示注入、间接注入、RAG 投毒、工具投毒、越权检索、敏感信息外泄、多轮诱导、错误自动处置，都应该沉淀成持续测试用例。
第五，建立运行时策略中心。AI 安全不是靠一次评审解决的。工具权限、敏感数据、风险动作、人工确认、沙箱策略、外联策略，都需要能持续调整。
第六，建立复盘回灌机制。每一次失败的提示注入、误调用、误封禁、越权检索，都应该回到规则、评测、策略和安全基线里。否则 AI 安全永远停留在人工救火阶段。
这里会出现一个自然方向：用 AI 管 AI。安全大模型可以参与恶意意图识别、工具投毒检测、告警研判、漏洞修复建议和策略编排。但这不代表 AI 可以完全接管安全运营。
封禁、删除、转账、生产变更、权限调整这些高风险动作，必须分级授权，并保留人工确认和回滚机制。
自动化不是目的，可控才是目的。
四、安全债会进入架构
普通应用可以先上线，再根据漏洞、告警和合规要求逐步加固。AI 系统不一样，它的安全边界和能力边界高度绑定。如果一开始就让模型默认接触所有数据、默认继承用户权限、默认调用所有工具、默认记录所有上下文，后面再想拆开，会非常困难。
安全债会进入架构。知识库一旦没有权限模型，后面补权限就是重建数据体系。Agent 一旦默认继承用户权限，后面补身份治理就是重构执行链路。工具市场一旦自由接入，后面补准入和审计就是重建供应链。个人 Agent 一旦默认可以直接发送邮件、上传文件、点击支付、授权第三方，后面再补监督机制，也会遇到体验和习惯阻力。
这就是 AI 安全和传统安全最不同的地方。
AI 安全不是上线后的外挂能力，而应该是系统设计阶段的默认能力。
尤其是 Agent 场景。Agent 的价值来自执行能力，而执行能力天然绑定权限、工具和数据。如果安全边界不在设计阶段定义清楚，后面每提升一点自治能力，都会同步放大风险。
所以 AI 安全不能等到规模化之后再补。
等 AI 已经深入业务流程、数据系统、生产环境和个人数字生活之后，安全债会变成架构债，架构债最终会变成治理债。
五、现在 AI 安全到底怎么样了
现在 AI 安全的整体状态，可以概括成一句话：模型侧开始成熟，系统侧还在补课，执行侧刚刚暴露。
模型安全已经有框架，有评测，有红队，有厂商投入。虽然远远不完美，但方向已经明确。
应用安全还在补工程欠账。很多企业知道要做 AI，但不知道 AI 应用应该如何接入权限、数据、日志、审计和安全评估。
Agent 安全刚开始进入真实风险区。因为过去很多 Agent 只是 Demo，现在才开始连接真实工具、真实账号、真实数据和真实流程。
个人 Agent 安全还处在更早期。它依赖真实浏览器、真实邮箱和真实登录态，但运行时监督、边界确认、草稿优先、敏感内容识别这些机制还没有形成标准体验。
工具链安全正在变成新供应链安全。Skill、MCP、插件、工具描述、返回值、外部 API 都会成为新攻击面。
治理运营安全会决定企业和个人能不能规模化使用 AI。没有持续审计、策略更新、红队复盘和回滚机制，AI 系统越多，风险越不可控。
AI 安全不是发展得太快，也不是发展得太慢。它真正的问题是：模型层跑得最快，系统治理层没有同步跟上；企业侧开始意识到隔离和治理，个人侧还没有形成成熟的监督机制。
总结
AI 安全现在最重要的变化，不是多了几个新漏洞，也不是多了几种新攻击方式。
真正的变化是安全对象变了。
过去，我们保护的是网络、主机、账号、应用和数据。现在，我们还要保护上下文、提示词、RAG 检索结果、工具描述、Agent 记忆、任务规划和模型行为。
过去，我们关心谁登录了系统。现在，我们还要关心 Agent 代表谁执行。
过去，我们关心账号有没有越权。现在，我们还要关心正常权限有没有被错误使用。
过去，我们关心代码有没有漏洞。现在，我们还要关心外部文档、工具返回值和自然语言描述有没有污染模型决策。
这就是 AI 安全的核心变化：从单纯的模型护栏问题变成了企业执行体系和个人数字生活的安全问题。
企业 Agent 的安全重点是隔离、授权、审计和回滚。个人 Agent 的安全重点是监督、解释、确认和可撤销。两者都属于 AI 安全，但不能用同一套方案粗暴解决。
如果说 AI 正在重写业务流程、研发方式、运维方式、安全运营方式和个人电脑使用方式，那么 AI 安全要做的，就是把这些新流程重新放进一个可理解、可审计、可控制、可回滚的体系里。
没有这套体系和边界，自治就是风险；有了这套边界，自治才是生产力。
