▍以下正文内容基于英文原文编译，可能存在语义偏差，请以原文为准。

AI生成工作流程的安全问题不在于它们失效，而在于它们运行了，却没人能解释是怎么运行的。

BNSF Railway的网络安全工程师Yelena Mujibur Sheikh在Dark Reading上写道："团队正在应对一个真正危险的问题——自动化有效，但没人理解。"

这一观察比大多数厂商威胁报告更加直白，也更有用。Sheikh描述的模式在快速采用AI工具的组织中很一致：开发者或分析师使用AI助手生成工作流程，工作流程解决了眼前问题，被部署了，然后悄悄地积累了从未被正式授予的访问权限。没人审查底层逻辑，没人绘制它触及的数据图谱。它就这么运行着。

权限问题是结构性的，而非偶然的

AI生成的代码倾向于请求广泛权限，因为这是生成可运行代码的最简单路径。模型优化的是能运行的代码，而非最小权限代码。结果是自动化通常持有比任何人工审查员会自觉批准的更多的访问权限。

Veracode关于AI生成代码安全性的研究发现，不安全模式和漏洞依赖项在大语言模型生成的代码中定期出现，并非因为模型是恶意的，而是因为它们在包含这些模式的代码库上训练的。输出反映输入。如果训练数据包含范围不当的服务账户和硬编码凭据，生成的代码就会复制它们。

第二个结构性问题，是Sheikh等人所说的"影子自动化"——在正式IT治理之外部署的AI生成工作流程，通常由可直接访问低代码或无代码平台的业务团队创建。这些工作流程不会出现在资产清单中，不在访问审查范围内，安全团队无法监控他们看不到的东西。

中毒模型与级联输出

更严重的风险在上游。当进入自动化决策工作流程的AI模型被破坏或操纵时，后果不会停留在本地。中毒的模型可以静默批准欺诈交易、生成虚假商业智能，或以看似正常运营的方式错误路由数据——直到损害已经造成。

Dark Reading在2025年5月报道了一个相关攻击类别：提交给AI编码代理的虚假bug报告，导致代理大规模地将恶意代码引入代码仓库。代理不知道bug报告是伪造的，它处理输入、生成修复并提交。在许多配置为信任代理输出的CI/CD管道中，没有人在代码进入生产环境前审查更改。

这就是具体的级联问题。一个被操纵的输入，由一个受信任的自动化系统处理，传播到每个下游依赖项。使AI辅助开发具有吸引力的速度特性，正是使输入不可信时变得危险的相同属性。

部署前值得实施的三个控制措施

这里的缓解措施都不新鲜。它们与任何自动化系统适用的控制措施相同，只是应用于组织一直视为豁免的这一类自动化。

部署前审查AI生成的代码，而非部署后。这意味着将AI辅助输出视为任何外部依赖项一样对待：静态分析、依赖扫描，以及了解代码做什么和能访问什么的人工审查员。将代理输出直接接受到生产管道而非进行此步骤，不是速度优化，而是未审查的变更控制。

在创建时限定权限范围，而非事后补救。请求广泛访问权限的AI生成工作流程应在审查时被质疑，而非等到安全审计发现暴露后才进行修剪。最小权限默认值需要在平台层面执行，而非留给开发者手动应用。

现在就绘制你的影子自动化图谱。任何使用低代码或无代码AI平台构建连接到生产数据或系统的工作流程的团队，都应被要求向IT注册这些工作流程。清单不需要复杂，只需要存在。你无法监控你不知道在运行的工作流程的漂移。