当 AI Coding、智能体、模型调用、插件工具和 AI 供应链逐渐进入真实业务企业对于 AI 安全的关注点也在发生变化。早期阶段企业首先考虑的是模型是否可用、业务场景是否成立、AI 应用能否顺利接入现有系统。但当 AI 从辅助工具进一步进入研发、办公、数据分析、业务运营甚至自动化执行环节之后一些更具体的问题开始出现AI 生成的代码应该如何验证智能体调用工具时权限边界如何确认Skill、MCP 和 Tool 引入之后企业是否真正了解它们的行为模型、组件、数据集和插件来自哪里发生新的供应链风险后又如何判断自身是否受到影响这些问题表明企业 AI 安全正在从单纯的“模型安全”逐步扩展至覆盖研发、智能体、工具调用和供应链的系统性安全问题。海外 AI 安全领域围绕 Mythos 所展开的一些实践也反映出类似趋势对于进入关键业务环境的 AI 系统仅仅发现问题并不足够还需要进一步完成评估、验证、证据留存和复测。如果把这一思路放到国内企业的实际环境中AI 安全建设同样需要从“检测一个模型”逐渐走向“验证一套 AI 系统”。一、AI 安全为什么越来越像一个系统工程AI 应用与传统软件有一个明显区别它很少独立存在。在研发环境中AI Coding会读取项目上下文、生成代码、修改代码并与IDE、代码仓库和CI/CD流程发生交互。在业务环境中Agent可能连接知识库、数据库、文件系统、办公平台或者第三方API并通过Tool执行具体动作。与此同时一套AI应用背后还可能依赖基础模型、开源框架、数据集、Skill、MCP服务以及大量第三方组件。因此风险也会沿着这些关系发生变化。例如模型本身可能没有明显问题但它调用的某个工具存在过高权限一个Skill功能正常却可能包含异常依赖某个AI组件上线时安全几周后却可能因为上游漏洞或者供应链事件产生新的风险。所以对于正在规模化部署AI的企业而言仅仅回答“模型是否安全”已经不够。还需要进一步回答代码是否经过验证、智能体行为是否符合预期、工具调用是否越界、第三方依赖是否可信以及这些风险是否能够持续被跟踪。这也是AI部署安全验证逐渐受到关注的原因。它不是增加一次扫描而是试图把安全能力嵌入AI从开发到上线再到运行的整个过程。二、第一道验证发生在代码进入工程体系之前AI Coding普及之后代码生成速度明显加快。过去开发人员完成代码编写后再进入代码检查、测试和安全审计环节。现在开发人员可能在很短时间内通过AI生成多个函数、模块甚至较完整的业务逻辑。效率提升的同时也对原有代码安全流程提出了新要求。因为AI生成代码并不会天然规避传统软件中的安全问题。权限判断、输入校验、数据流处理、接口调用以及业务状态控制依然需要进行工程化验证。因此一个越来越现实的思路是把代码安全能力进一步向研发前端移动。以悬镜安全灵脉CodeAI为例其关注点并不只是在代码生成完成后增加一次AI审查而是结合静态分析、代码关系分析和多Agent推理对项目中的调用关系、数据流、控制流以及业务逻辑进行进一步分析。在AI Coding场景中这类能力更适合作为现有研发安全流程的一部分生成代码之后进行安全检查代码发生变化后重新判断风险发现问题后进入已有的分配、修复和复测流程。从企业视角来看真正重要的不是“AI能不能检查AI生成代码”而是AI生成代码之后企业原有的软件安全质量控制机制是否仍然有效。这也是AI研发安全需要解决的基础问题。三、智能体安全的重点正在从“回答什么”转向“执行什么”相比普通大模型应用Agent带来的变化更加明显。一个聊天机器人主要输出文本但一个智能体可能真正执行操作。例如它可以查询数据库、读取文档、调用业务API、创建任务、修改文件甚至根据用户目标连续调用多个工具。这意味着安全问题也会从传统的内容输入输出进一步扩展到行为过程。一个智能体可能回答得完全正常但在工具调用过程中发生权限越界也可能因为间接提示词影响选择了错误的执行路径还可能因为接入第三方Skill或者MCP服务引入新的代码、数据和供应链风险。因此智能体上线前需要验证的并不是一个单独模型而是一条完整调用链。目前国内一些AI安全产品也开始向这个方向发展。例如问境AIST围绕模型、Agent、Skill、MCP和Tool等对象开展风险测试希望回答的核心问题是这些AI资产之间形成连接之后是否会产生新的安全风险。其中Skill是比较值得关注的一类对象。对于业务人员而言一个Skill可能只是“读取表格”“生成报告”或者“查询信息”但从安全角度看它背后可能涉及脚本执行、文件读取、网络访问、接口调用以及第三方依赖。因此对Skill的检查通常不能只看功能描述。还需要进一步分析它包含什么、可能执行什么、依赖什么以及运行之后会发生什么。这类测试的意义在于把原本比较模糊的“这个智能体看起来安全吗”转化成更具体的问题它访问了什么、调用了什么、是否越权、是否存在异常行为以及相关证据是什么。对于AI部署决策而言这类证据往往比单一风险评分更加重要。四、AI供应链正在成为新的风险来源AI应用的另一个变化是供应链结构明显变得更加复杂。传统软件供应链主要关注代码、开源组件、依赖包和构建流程。进入AI时代之后模型、数据集、Agent框架、Skill、MCP Server、插件和第三方AI服务也加入其中。企业因此面对一个新的问题自己到底依赖了哪些AI资产如果一个开源模型曝出安全问题企业需要知道哪些业务使用了它如果某个Skill出现投毒风险需要判断内部是否已经安装如果某个MCP服务存在漏洞需要快速找到哪些Agent与它建立了连接。因此AI供应链安全并不仅仅意味着“检测第三方组件”更重要的是建立外部风险变化与企业内部资产之间的关联。以云脉AI所覆盖的AI供应链安全情报场景为例相关能力主要关注模型、Agent、Skill及其他AI生态组件中的新增漏洞和供应链风险并尝试与内部资产进行关联。从治理逻辑来看这实际上解决的是一个很基础的问题当外部世界发生变化之后企业能不能快速知道“这件事与我有没有关系”。这一能力对于长期运行的AI应用尤其重要。因为上线前安全并不意味着上线后永远安全。五、AI安全最终仍然要回到软件工程体系讨论AI安全时很容易形成一个误区似乎需要重新建设一整套完全独立于传统安全体系之外的新平台。但从企业真实环境来看AI应用最终依然运行在软件工程体系之中。代码仍然存放在代码仓库里组件仍然存在依赖关系接口仍然需要进行测试漏洞仍然需要进入整改流程系统最终还是要经过发布、运行和持续运营。因此AI原生安全与软件供应链安全之间并不是替代关系。更多时候两者需要发生连接。比如AI生成的代码仍然需要代码安全分析Agent调用的接口仍然属于应用攻击面AI应用使用的开源组件仍然需要进行供应链风险管理AI安全测试发现的问题最终仍然需要进入企业已有的漏洞治理和安全运营流程。这也是为什么在实际建设过程中AI安全能力往往需要与SCA、IAST、动态安全验证以及ASPM等已有能力发生协同。悬镜安全目前的产品体系也体现了这种思路灵脉CodeAI、问境AIST和云脉AI分别面向AI研发、AI应用测试及AI供应链情报而源鉴SCA、灵脉IAST、灵脉PTE和夫子ASPM则继续承担软件供应链和应用安全治理中的不同环节。真正值得关注的不是产品数量而是这些环节能否共享风险信息。如果一个风险在代码阶段已经被发现那么后续测试是否需要重复验证如果动态验证确认漏洞真实可利用那么漏洞优先级是否应该发生变化如果新的供应链情报出现系统能否自动找到对应资产这些问题决定了AI安全最终能否从“工具建设”转变为“治理能力”。六、从风险检测走向部署验证如果以Mythos相关实践作为观察窗口可以看到AI安全正在出现一个比较明显的方向从判断“有没有风险”进一步转向判断“是否可以部署”。两者看起来相近实际上解决的问题不同。检测工具通常回答这里有没有问题而部署验证需要进一步回答问题是否真实影响范围是什么有没有完成整改是否经过复测目前剩余风险是否能够接受企业能否留下完整的验证证据因此一个相对完整的AI部署安全验证过程至少可能涉及四个环节。第一是识别。企业首先需要知道自己有哪些模型、Agent、Skill、MCP、Tool以及相关组件。第二是验证。通过代码分析、Agent安全测试、红队验证或者动态行为测试确认风险而不是简单停留在告警层面。第三是持续感知。AI生态变化很快上线之后还需要持续关注模型、组件和供应链的新风险。第四是治理。测试结果需要能够进入修复、责任分配、复测、审计以及上线决策流程。这四个环节共同决定了一套AI安全能力是否能够长期运行。七、中国企业可能需要什么样的AI部署安全体系不同企业的AI应用方式差异很大因此并不存在一套完全统一的建设模式。但从当前的应用趋势来看未来企业AI安全体系大概率需要同时具备几个特点。首先它需要覆盖的不只是模型。代码、Agent、Skill、MCP、Tool以及AI供应链都将逐渐进入安全治理范围。其次安全能力需要尽量靠近研发和上线流程。如果每次安全检查都需要人工发起、人工整理、人工确认很难跟上AI应用快速迭代的速度。再次检测结果需要尽量形成证据。对于企业而言“发现一个风险”和“证明这个风险真实存在”是两回事。后者更有利于研发、安全和业务之间达成一致。最后AI安全还需要具备持续性。今天完成安全验证并不意味着一个月之后模型、组件和Skill仍然保持原来的风险状态。因此真正适合企业规模化AI应用的安全机制更接近一种持续的验证过程而不是一次性的上线检查。结语AI正在从一个提高效率的辅助工具逐渐成为企业研发和业务流程中的实际参与者。它开始生成代码、理解任务、调用工具也开始直接连接企业数据与业务系统。与此同时AI安全的边界也在不断扩展。模型安全依然重要但代码安全、Agent行为安全、Skill和MCP安全以及AI供应链风险正在成为同样需要关注的问题。从Mythos所代表的海外探索到国内企业正在推进的AI安全实践一个逐渐明确的趋势是AI规模化部署需要与之匹配的安全验证机制。对于企业来说下一阶段真正值得思考的可能已经不是“要不要做AI安全”而是如何把AI安全变成研发、上线和运营过程中可以持续运行的一部分。围绕这一方向包括悬镜安全在内的国内安全厂商也正在尝试将AI原生安全能力与既有的软件供应链安全体系连接起来在AI Coding、智能体安全测试、AI供应链情报和应用安全治理之间建立更连续的验证链路。最终目标并不是增加更多安全工具而是让企业在使用AI之前和使用AI过程中都拥有更充分的风险判断依据。当AI开始参与越来越多真实业务这种能力也将逐渐成为企业AI工程体系的一部分。