我让AI智能体运行我食品公司的日常运营。真正的风险不是糟糕的输出,而是写入权限。
摘要
作者分享了他们用AI智能体运营一家食品公司的经历,发现真正的风险不是糟糕的输出,而是过度的写入权限,而通过沙箱隔离并对出站操作进行人工审批是关键解决方案。
我经营一家小型食品公司的第一个月,都是在使用AI智能体(每个负责一部分工作的小程序),当时我假设风险在于软件把事情搞错。事实并非如此。风险在于一个能读取一切、写入一切的程序。初期,我的智能体拥有广泛的数据库访问权限,因为这样连接起来更快。没有发生什么灾难性的事情,但我注意到,每次我交接一个新任务时都会紧张,因为我无法确定程序能操作什么,而只能查看什么。解决方案很无趣。给每个新系统自己的数据库、自己的表,并把任何离开该沙箱的内容放到一个人工审批队列后面。真实数据只有读取权限。写入权限仅限于它自己的隔离存储。没有人工批准,任何东西都不能出去。软件质量并不是我得到的教训。这些程序现在在实际工作中表现不错,比我一开始预期的要好。真正浪费时间的是没有先考虑边界。事后我花在构建读写墙上的每一个小时,都是本可以用来改进工作本身的。我要反驳的炒作是:认为更聪明的模型能自行消除风险。对我来说,这并不能解决任何问题。真正起作用的是在一切面向外部的操作周围设置一道硬墙。我很好奇,其他用AI运营业务的人是否也得出了同样的规则——读取一切,在自己的沙箱之外不写任何内容——或者发现了更重要的其他边界。
相似文章
这里有人运行能够实际写入生产系统的AI agents吗?
一位用户正在寻求其他运行具有写入生产系统权限的AI agents的实践经验,讨论如操作验证、重试处理、审计跟踪和内部所有权等运营挑战。
如何防止AI代理在生产环境中采取意外或有害行动
一位开发者探讨了在不造成意外损害的情况下将AI代理部署到生产环境的挑战,并寻求关于最小权限、影子模式、速率限制和审批工作流程等控制机制的建议。
在生成环境中运行AI代理:如何控制它们实际允许执行的操作?
一位开发者寻求关于如何在生产环境中控制和约束AI代理行为的建议,特别是当它们与真实系统(如数据库和客户数据)交互时,询问当前实践情况以及这是否是一个已知的难题。
你们当中那些在生产环境中运行AI代理的人——实际上是如何管理它们的权限的?
本文探讨了工程师如何管理生产环境中AI代理的权限,强调了普遍存在的权限过大和缺乏审计追踪的问题。
感觉人们给AI智能体赋予生产环境访问权限过于随意了。
一条推文表达了担忧:开发者在不充分理解安全性的情况下,赋予AI智能体对生产环境、内部工具和API的过度宽松访问权限,并指出随着这些系统变得更加自主,风险正在增大。