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