当你的智能体调用另一家公司的智能体时——谁在真正验证握手?
摘要
一位开发者描述了当一个AI智能体调用第三方供应商的智能体时遇到的认证和授权漏洞,重点说明了权限提升、未验证链和混淆代理攻击等故障模式。他们向社区询问如何处理跨组织智能体调用验证。
构建一个多智能体系统,其中我们内部的一个智能体需要调用第三方供应商的智能体来触发订单履行。集成工作很简单。阻止我的是一个我找不到干净答案的问题:当我们的智能体调用他们的智能体时,每一方都有自己的认证层——我们验证我们颁发的令牌,他们验证他们颁发的令牌。但没有人独立验证它们之间的握手。具体遇到了三种故障模式,我无法看到如何通过任何一方的现有认证来捕获:1. 我们的智能体拥有一个作用域为 read_order 的有效令牌。它请求在供应商系统上执行 execute_payment,声称继承自之前步骤的权限。供应商的认证系统验证“这是来自可信颁发者的真实令牌吗?”——是的——但从不检查该令牌是否实际具有支付操作的作用域。2. 请求链从未经验证的用户输入(自由文本表单提交)开始,通过我们的智能体,到达供应商的智能体时看起来像一个内部已验证的请求。双方的认证都无法看到完整的链历史。3. 供应商的智能体已注册且可信。但一个声称来自我们这边的请求实际上是通过供应商的智能体将调用反弹回内部——这是一种跨组织的 CONFUSED_DEPUTY。双方各自的认证系统都通过了。你在实践中遇到过这种情况吗?你是如何处理跨组织智能体调用验证的?你是在协议层面(A2A/MCP)、在应用层解决的,还是暂时将其视为已知差距?不是想找产品推荐——真诚地想知道这是否是其他人遇到过的真实操作问题,还是我想得太复杂了。
相似文章
我询问了20位Agentic AI创始人如何处理智能体访问权限。17位表示依靠临时权宜之计。
作者调查了20位Agentic AI创始人,发现由于缺乏可验证的授权层,其中17位依靠临时权宜之计来处理智能体访问控制。这突显了处理敏感数据的AI智能体在安全性和审计方面存在显著差距。
智能体跟进与验证问题
用户描述了AI智能体在接收任务后不反馈的问题,并向社区寻求解决方案和处理方法。
当你从一个AI代理扩展到多个时,最先出问题的是什么?
讨论从单个AI代理扩展到多个时出现的运营挑战,包括上下文交接、认证权限、重复工作和成本跟踪。
如果 AI 代理无处不在,我们如何知道哪些值得信任?
随着 AI 代理变得无处不在,挑战从比较性能转向建立信任和声誉,需要新的发现和验证系统。
当第三方服务在工作流程中宕机时,你的智能体该如何应对?
探讨AI智能体在工作流程中第三方服务出现故障时应如何处理,强调了自主系统中稳健错误处理的必要性。