一个能调用另一个代理的代理已经提升了其自身权限

代理通常通过缩小其工具列表来限定范围。该列表被视为爆炸半径。五个工具，审查这五个，边界就清楚了。边界是单跳深度的。如果任何允许的工具能通过生成调用、服务端点、其他组件监听的队列或工作流触发器访问另一个代理，那么实际能力集是所有可达代理的传递闭包。被审查的只是第一跳列表。旨在跨跳持续的约束通常转化为提示文本。 “仅处理租户42。” “保持在五十美元以下。” 下游这些句子只是建议。数据库不会检查它们。支付API也不会检查它们。那么问问如果子代理忽略这个句子会发生什么，如果答案是它根本不会，那么一个建议就被当作了权限。事后重建也很尴尬。通过委托的权限提升不会产生看起来像提升的日志行。子代理使用自己的真实凭据做它被允许的事情，链中的每一跳都是单独授权且单独乏味的。记录中缺失的是因果部分，即整个事件追溯到一个没人授予其访问权限的代理。低成本检查。拿工具允许列表，对每个条目询问其另一端是否本身就是一个代理。如果答案是肯定的，要么在生成时铸造更窄的凭据，让资源而不是模型来执行约束，要么接受边界是单跳深度的，并明确说明。明显的反对意见是合理的，而且大多数时候确实如此。在许多技术栈中，子代理是同一进程中具有相同凭据的相同信任边界内的组件，所以也许这个区分的好处不如听起来那么大。真正棘手的是跨进程或组织边界的委托，或者能比父运行活得更久的子代理。不受信任的输入引导委托决策是同一问题更糟糕的版本。你是为每个子代理限定凭据范围，还是通过提示文本传递约束，你的框架实际上让什么变得容易？