在生产环境每条命令路径中运行AI审核员六个月(它对安全团队的影响出乎意料)

Reddit r/AI_Agents 新闻

摘要

一个开源访问网关部署了基于LLM的审核员用于生产命令;出乎意料的是,安全团队的角色从二元把关人转变为AI代理的判断层。

我负责一个开源访问网关。我们已经在生产环境中,对每个生产命令路径部署了基于LLM的审核员,并运行了大约六个月,有客户在生产中使用。令人惊讶的不是技术层面,而是组织层面。一开始,我们假设LLM会改变开发者的工作方式——减少手动审批、加快迭代、降低低风险命令的摩擦。这些大致如预期发生。但安全团队的变化是我们未曾预见的。在AI审核员之前,安全团队与生产访问的关系是二元的:要么他们审核某些东西,要么不审核。大多数事情属于后者。没有带宽去检查每条命令,因此审核集中在明显敏感的界面上,其余部分则依赖静态策略和定期审计。一旦AI审核员介入,关系就发生了转变。模型处理了团队无法处理的量。它标记看似有风险的内容,对上下文进行初步判断,并应用团队先前的指导。团队不再成为每条命令的瓶颈,而是开始充当模型所呈现内容的判断层。我没有预料到的是:安全团队的人开始像谈论同事一样谈论这个审核员。现在常用的术语是“agent-in-the-loop”(代理参与循环),而这个循环中有两个代理:一个用于开发团队发布变更,另一个用于安全团队审核它们。安全团队不再管理开发团队,而是开始管理开发团队的代理。如果对其中任何一点感兴趣,我很乐意深入探讨。
查看原文

相似文章

Azure DevOps MCP 与代理 PR 审查中的混乱代理问题

Reddit r/AI_Agents

一份关于微软 Azure DevOps MCP 服务器的报告揭示了一种混乱代理攻击:隐藏的 PR 文本可以操纵 AI 审查代理(Copilot CLI、Claude Code)以用户的权限进行非预期的工具调用。建议包括使用只读身份并要求单独的审批步骤。