谁授予了你的AI代理权限?
摘要
讨论AI代理工作流中的安全漏洞,即代理在关键步骤中假设存在人类监督,并提出了一个运行时控制平面,用于强制执行权限,并在破坏性操作前要求人工批准,通过Tandem演示进行了说明。
在大多数代理工作流中,我们基本上假设代理在到达关键节点时会停下来询问。例如,当代理可以发送邮件、删除文件、修改仓库或触碰生产系统时,我们期望它在执行破坏性操作前先征求许可。这在演示中或许没问题。但在生产环境中,我不认为这能通过严格的首席信息安全官/安全审查。随着像OpenClaw和Hermes这样的代理工具开始在公司内部执行实际工作,这个问题变得更加明显:公司不会允许代理仅以提示作为安全边界来运行。破坏性操作、数据泄露或工具滥用的风险太高了。如果答案不是更好的提示,而是一个决定代理在每一步拥有什么权限的运行时/控制平面呢?我围绕这个想法构建了一个小的Tandem演示:代理起草一封邮件,但运行时在发送前阻止它,等待人工批准,然后继续并附带审计跟踪。请查看评论中的演示。在信任代理使用真正的公司工具之前,你期望哪些控制措施?
相似文章
当AI智能体采取实际行动时,授权究竟在哪里执行?
探讨了当AI智能体采取实际行动时执行授权所面临的挑战,提出了安全控制应置于何处的问题。
我们尚未讨论的 AI 代理中的显性安全漏洞:输出即权威的那一刻
本文强调了 AI 代理中的一项关键安全漏洞,即输出执行绕过了适当的权限检查,主张在授予受信任的上下文或密钥之前设置“外部准入”门禁。
AI 代理最危险的部分始于其获得执行权限之时
本文强调了 AI 代理获得基础设施执行权限所带来的关键风险,认为如果没有外部准入层来防止灾难性故障,现有的安全护栏是不够的。
对于能够执行实际操作的AI代理,你们如何处理权限和授权?
这是一个讨论帖,征求关于如何处理能够执行实际操作的AI代理的权限和授权(包括审计追踪和权限范围)的意见。
对于使用工具的智能体,安全边界应划在哪里?
讨论AI智能体使用工具的安全风险,重点关注提示注入这一实际威胁——不受信任的文本可能改变智能体行为,以及在授予权限前需要进行可重复测试。