我给了一个 AI 智能体对客户 ERP 系统的写入权限。以下是它在无人指示的情况下自行采用的安全措施。
摘要
一位顾问分享了一个 AI 智能体在获得客户 Odoo ERP 系统的写入权限后为自己设定的行为边界:归档前先征求同意,拒绝高风险合并,清理前先核实,保存可供撤销的操作清单,发现连带影响,并主动报告自身故障——无需任何框架,只需遵循“计划—审批—执行—记录”的流程。
我为一家建筑行业客户做一些咨询工作,他们的项目、工时表和费用都在 Odoo 里管理。我的一个智能体在 Odoo 聊天里有自己的用户账号。我在那里给它发消息,客户的项目经理也可以,而且它会记住上次读到哪条消息,下次就从那里接着处理。我终于翻了翻它的工作文件,看看它到底在做什么。大部分事情都发生在一个下午:**它在归档前先征求了同意。** 它找到了 27 个日期已过的投标项目,但没有获得归档许可。于是,它给项目经理发了一份编号列表,请对方回复“全部归档”或相应的编号。得到同意后,它将这 27 个项目全部归档。**它拒绝在合并时瞎猜。** 有几个项目存在重复记录。每次合并前,它都会检查哪些内容将被迁移,在两条记录上都留下备注,然后归档旧记录。其中一个项目找不到对应的重复记录,所以它将其标记为受阻,并告诉我原因,而不是挑一个名字最接近的凑数。**它在清理前先做了检查。** 在归档 7 个共享工作流阶段前,它确认了 148 个项目中没有任何一个仍在使用这些阶段。是归档,不是删除。**它会保存撤销清单。** 它的许多结果文件末尾都会列出它所创建记录的确切 ID,这样运行出错时就能撤销。那次阶段调整还保存了每个被移动项目的完整映射。**它发现了一个副作用。** 关联任务时,ERP 自动给 3 个原本没有销售订单行的项目关联了销售订单行。它撤销了这些关联,并报告了此事。**它宁可留空,也不瞎猜。** 一个新项目需要一张发票草稿,但系统里没有小时费率。它把发票金额留在 $0.00,并注明“仍需提供费率”。**它会报告自身的服务中断。** 有一天连接不上服务器时,它记录了这次失败,也没有推进消息列表的读取位置,因此没有漏掉任何消息。这些都不是什么框架。无非是制定计划、获得批准、执行操作,再记录如何撤销。对于那些允许智能体写入生产系统的人:你们要求哪些防护措施?你们会让智能体先询问,还是允许它直接行动,再依靠撤销来兜底?
相似文章
我们的 agent 有一条硬性规则:永远不要在 ERP 里改写任何内容。原因和 AI 毫无关系。
BotsCrew 分享了一个采购代理(procurement agent)的案例研究。该代理最严格的护栏——绝不重写 ERP 确认单——并非出于对幻觉的担忧,而是因为 ERP 在重新确认时会清空行项目备注。一次保留备注的 ERP 更新解锁了一个必需的工作流程,这说明智能体的上限往往是记录系统(system of record),而非模型本身。
高风险操作应事先获得批准,而不是事后审查。赋予智能体对 CRM、发票和日历的写入权限所带来的经验教训
Conecto 的创始人分享了让 AI 智能体拥有 CRM、发票和日历写入权限的实践经验,主张高风险操作应事先获得人工批准,而不是事后审查。关键做法包括在工具描述中注明价格、使用幂等键确保重试安全、为高风险写入设置审批关卡,以及将预算上限作为安全保障。
我让AI智能体运行我食品公司的日常运营。真正的风险不是糟糕的输出,而是写入权限。
作者分享了他们用AI智能体运营一家食品公司的经历,发现真正的风险不是糟糕的输出,而是过度的写入权限,而通过沙箱隔离并对出站操作进行人工审批是关键解决方案。
你实际上允许AI代理对生产系统进行写入操作的程度如何,而不只是起草或建议?
讨论探讨了允许AI代理在ERP和CRM等生产系统中进行无监督写入操作的当前立场,质疑行业中的障碍和舒适度。
AI代理失误
这篇文章询问了关于AI代理进行未授权行为的经历,并讨论了安全措施如账本和受控权限以防止此类问题。