我们尚未讨论的 AI 代理中的显性安全漏洞：输出即权威的那一刻

大多数关于 AI 安全的讨论仍停留在模型层。提示词是否安全？是否存在幻觉？是否泄露数据？是否遵循了护栏限制？当然，这些都至关重要。但让我感到恐惧的，是发生在下一层的情况。那是代理停止生成文本并开始触及执行层的精确时刻。它创建分支。发起 PR（Pull Request）。触发 CI（持续集成）。请求密钥。获取云角色。启动部署路径。它在生产环境中签署、购买、修复或删除某些内容。此时，仅问“AI 生成的输出质量如何？”已不再足够。真正的问题是：“在此上下文中，具有此意图的该行为体，是否真的有权采取行动？” 我们几乎未谈及这一边界。相反，我们不断堆叠日志、监控、护栏、审批步骤和仪表盘。它们确实有帮助，别误会我。但几乎所有这些措施都是在执行期间或事后运行的。最极端的故障模式是：系统完全按设计运行。凭证有效。工作流看起来正常。日志显示绿色。策略检查通过。然而，该动作从一开始就不应被允许启动。 我们在各处都能看到这种情况：PR 标题意外成为 shell 输入。由代理创建的分支轻松进入受信任的 CI。基本工作流挂钩到 OIDC 身份。看似次要的令牌路径升级为云权限。看似“无害的自动化”路径摧毁了真实的生产环境。一旦代理能够接入受信任的环境，“它能做这件事吗？”就成为了错误的起点。第一个必须提出的问题必须是：“在授予任何权限之前，该动作是否已被准入？” AI 代理安全的下一个时代，不仅仅关乎更好的提示词或事后日志监控。它关乎在发出受信任的执行上下文之前的一道硬性边界。在获取密钥之前。在获得 AWS/Azure 角色之前。在获得部署权限之前。在进行支付之前。在访问生产环境之前。 不应仅因代理或自动化路径请求，就授予受信任的上下文。行为体 + 意图 + 请求上下文的组合，必须在权限存在之前由外部门禁清除。否则，我们并非在控制执行，只是在旁观它发生。 我将此称为执行前的外部准入。它并非日志、护栏或监控的替代品。它是一个更基础的门禁：受保护的动作是否能在没有明确的“外部确认”的情况下执行？如果答案是肯定的，你可能拥有出色的治理、清晰的日志和精美的仪表盘。但你没有外部准入边界。