我们让AI代理访问数据库、邮件系统和支付API。然后我们只是……信任它们。
摘要
本文强调了当前对能够访问数据库、邮件系统和支付API的AI代理严重缺乏治理层,指出目前在没有监督的情况下信任LLM的做法危险且不足。
想想我们实际在做什么。我们构建一个AI代理。我们给它工具——读写数据库的能力、代表我们发送邮件、调用外部API,有时还能处理支付。我们测试它。它运行正常。我们部署它。然后我们回家,它无人监管地运行,在现实中采取实际行动,除了“LLM大概会保持在边界内”之外,对其所作所为没有任何有意义的检查。LLM并不总能保持在边界内。一个糟糕的提示、一个边缘情况、一条注入到代理读取的数据中的指令,它就会做出不该做的事。等你注意到时,事情已经发生了。我指的不是AGI风险。我指的是代理向未订阅用户发送500封邮件,或删除不应删除的记录,或将客户数据转发到它在不该使用的上下文中被要求调用的API。令人惊讶的不是这种情况发生,而是几乎没有人有治理层——策略执行、审计追踪、高风险操作的人工审批——位于代理和其工具之间。我们只是部署然后祈祷。我们构建了一些东西来解决这个问题,但我更感兴趣的是更广泛的问题:为什么这还不是标准做法?
相似文章
AI 代理最危险的部分始于其获得执行权限之时
本文强调了 AI 代理获得基础设施执行权限所带来的关键风险,认为如果没有外部准入层来防止灾难性故障,现有的安全护栏是不够的。
AI智能体很有趣,直到它们开始接触真实数据
文章探讨了AI智能体与真实公司数据和工具交互时出现的治理挑战,强调了策略执行和审计追踪的必要性,并提到Trust3 AI作为潜在解决方案。
感觉人们给AI智能体赋予生产环境访问权限过于随意了。
一条推文表达了担忧:开发者在不充分理解安全性的情况下,赋予AI智能体对生产环境、内部工具和API的过度宽松访问权限,并指出随着这些系统变得更加自主,风险正在增大。
给予AI Agent支付权限是否可行?
关于是否应给予AI Agent直接访问支付系统的讨论,权衡便利性与安全风险。
AI代理即将制造一个无人愿意承担的责任问题
随着AI代理从提供答案转向在实际工作流程中采取行动——例如处理付款、客户数据和审批——其错误缺乏明确问责制成为了一个关键问题。