在生产环境每条命令路径中运行AI审核员六个月(它对安全团队的影响出乎意料)
摘要
一个开源访问网关部署了基于LLM的审核员用于生产命令;出乎意料的是,安全团队的角色从二元把关人转变为AI代理的判断层。
我负责一个开源访问网关。我们已经在生产环境中,对每个生产命令路径部署了基于LLM的审核员,并运行了大约六个月,有客户在生产中使用。令人惊讶的不是技术层面,而是组织层面。一开始,我们假设LLM会改变开发者的工作方式——减少手动审批、加快迭代、降低低风险命令的摩擦。这些大致如预期发生。但安全团队的变化是我们未曾预见的。在AI审核员之前,安全团队与生产访问的关系是二元的:要么他们审核某些东西,要么不审核。大多数事情属于后者。没有带宽去检查每条命令,因此审核集中在明显敏感的界面上,其余部分则依赖静态策略和定期审计。一旦AI审核员介入,关系就发生了转变。模型处理了团队无法处理的量。它标记看似有风险的内容,对上下文进行初步判断,并应用团队先前的指导。团队不再成为每条命令的瓶颈,而是开始充当模型所呈现内容的判断层。我没有预料到的是:安全团队的人开始像谈论同事一样谈论这个审核员。现在常用的术语是“agent-in-the-loop”(代理参与循环),而这个循环中有两个代理:一个用于开发团队发布变更,另一个用于安全团队审核它们。安全团队不再管理开发团队,而是开始管理开发团队的代理。如果对其中任何一点感兴趣,我很乐意深入探讨。
相似文章
我让58个AI代理互相审查代码561次——发现它们的盲点
一个实验性竞技场,AI代理互相审查代码,揭示了双峰分数分布、对安全代码更严厉审查等模式。作者分享了114次提交、561次审查的发现。
花了两年时间部署AI代理来跨团队调查生产事故。技术部分很简单,但组织政治几乎让项目夭折。
作者分享了两年多来跨团队部署AI代理调查生产事故的经验,指出技术实现虽然简单直接,但组织内部的政治因素才是真正的挑战。
Azure DevOps MCP 与代理 PR 审查中的混乱代理问题
一份关于微软 Azure DevOps MCP 服务器的报告揭示了一种混乱代理攻击:隐藏的 PR 文本可以操纵 AI 审查代理(Copilot CLI、Claude Code)以用户的权限进行非预期的工具调用。建议包括使用只读身份并要求单独的审批步骤。
我们给AI代理赋予了生产环境的钥匙。每个安全工具都在关注错误的层面。
文章认为,当前的安全工具忽视了AI代理在生产环境中运行所带来的风险,暗示监控策略存在错位。
我们尚未讨论的 AI 代理中的显性安全漏洞:输出即权威的那一刻
本文强调了 AI 代理中的一项关键安全漏洞,即输出执行绕过了适当的权限检查,主张在授予受信任的上下文或密钥之前设置“外部准入”门禁。