当 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工程体系的一部分。