当AI代理跨越多个系统时,谁真正拥有权限?
摘要
本文讨论了跨越多个系统的AI代理工作流中权限和治理的挑战,质疑权限和策略如何在交易链中交互。
大多数关于AI代理权限的讨论都集中在代理本身。但一旦代理开始在多个系统间操作,权限就变得难以推理。想象一个交易经过:一个身份提供商、一个CRM、一个内部API、一个第三方模型、一个支付或交易系统、一个审批工作流。每个组件可能有自己的权限和控制。但谁对整个链条的权限负责?几个问题很快变得困难:在一个系统中建立的权限是否会延续到下一个系统?一个系统能否安全地依赖另一个系统的上下文或审批?当权限在工作流中途改变时会发生什么?如果两个系统应用不同的规则,哪个策略优先?最终行动能否追溯到证明其正当性的权限?如果组合序列的风险高于任何单个步骤,谁应该停止交易?这让我怀疑代理治理是否需要超越组件级别的身份和访问控制。真正的治理单元可能越来越多地是交易链。一个代理可能被授权执行每个单独步骤,但组合序列仍应被阻止。人们如何思考跨多系统代理工作流中的权限?
相似文章
对于能够执行实际操作的AI代理,你们如何处理权限和授权?
这是一个讨论帖,征求关于如何处理能够执行实际操作的AI代理的权限和授权(包括审计追踪和权限范围)的意见。
当AI智能体采取实际行动时,授权究竟在哪里执行?
探讨了当AI智能体采取实际行动时执行授权所面临的挑战,提出了安全控制应置于何处的问题。
如果一个AI代理可以调用20个工具,那么授权应该实际放在哪里?
探讨了当一个AI代理可以调用多个工具时,应该在何处实施授权的问题,讨论了安全访问控制的架构考虑。
谁授予了你的AI代理权限?
讨论AI代理工作流中的安全漏洞,即代理在关键步骤中假设存在人类监督,并提出了一个运行时控制平面,用于强制执行权限,并在破坏性操作前要求人工批准,通过Tandem演示进行了说明。
真的有人在执行AI治理,还是仅仅在制定政策?
文章讨论了书面AI治理政策与实际在运行时AI代理工作流中执行这些规则之间的差距。