据TechRadar于9月18日发布的文章，多数企业的影子AI项目已经完成发现阶段，查清内部使用的AI工具并建立清单，但项目随后停摆。报道认为，发现只能说明发生了什么，执行才能决定接下来会发生什么；企业若停留在清点层面，大量AI代理仍将在缺少安全监督和日志的情况下运行。

文章称，执行意味着在AI行动发生过程中改变其结果，而不是事后报告。对代理而言，执行包括四种干预方式：阻止工具运行、缩小其可触及范围、将特定操作置于审批之后，或在执行中途终止进程。这四种方式不能互换，选择哪一种本身就是主要工作。阻止最简单，但投诉最多；缩小范围最持久，却最难配置；审批只有在队列不流于形式时才有效；终止是最后手段，且必须在行动完成前落地。

报道指出，网络边缘封堵AI域名曾是许多组织的首选控制手段，部署容易，也便于向董事会解释，但它覆盖的实际风险份额正在缩小，因为AI已不再只是一个网站。本地模型不会发出可被检查的外连流量；嵌入式助手运行在已授权应用内部，其流量看起来像获批的供应商；IDE、命令行代理以及localhost上的MCP服务器，不会经过企业控制的网络边界；个人设备仍是更早存在的缺口，而AI工具免费且无处不在让问题加剧。

更深的难题在权限。文章称，代理使用人的身份和权限行动，日志会显示员工读取了文件，或凭证属于某个个人或服务账户，而现有身份控制只询问该主体是否被允许执行操作，答案通常是“可以”。身份基础设施从未被设计来回答的问题是：由软件代表人类采取的这一行动，是否属于人类会批准的行动。因此，AIUC-1等新兴标准将未经授权的代理行动、访问权限执行和不安全工具调用视为独立控制项，而不是并入一般访问管理。

报道认为，执行必须放在行动实际发生的位置，因为只有那里能给出确定性判断。指令层的输入过滤和提示词护栏值得部署，也能减少数量，但它们是概率性的，而且在语言模型中把指令与数据分开仍未解决。系统应按指令已经通过的情况来建设：如果代理的工具调用在触发时被限制、审批或停止，指令来源就不再重要。恶意提示、被投毒文档和诚实错误都会产生同样的被阻止行动。这也是端点与运行时位置在架构争论中持续占优的原因，因为几乎所有AI交互最终都会变成设备上的进程，本地模型、嵌入式助手和浏览器标签页都表现为正在执行的代码。

在落地方法上，文章建议把执行项目拆成不会引发剧烈反弹的步骤：先选择一个类别，而不是整个清单，例如一组有明显替代方案的被禁工具；先以监控模式运行两周，通常会找到没人告知的合法工作流；在对代理执行限制前，为每个代理指定负责人，无主代理无法被豁免或修复，会把阻止变成事故；在最小可行范围内开启阻止，再衡量投诉率后扩大；从第一天起把执行日志接入证据管道，事后补建比一开始内置更难。

文章还建议向领导层汇报时，先给出一个他们不喜欢的数字：无负责人、无日志、无控制的AI代理数量，这通常足以支撑项目预算；再承诺第二个数字：第一季度执行了多少次执行动作，并拆分为阻止和审批。报道称，从不阻止任何东西的控制不是控制，而是包装更好的报告。