你的智能体有权访问 delete_user() 吗?
摘要
文章讨论了AI智能体授权的复杂性,强调仅工具访问是不够的,基于上下文、策略和预算的运行时决策对于安全生产部署至关重要。
工具访问容易检查,但授权更复杂。假设一个智能体有权访问 delete_user()。这不能告诉你它可以删除哪些用户、在何时、在什么条件下,或者该操作是否需要批准。生产环境中的授权决策可能需要:智能体身份、工具身份、目标资源和环境、当前策略、执行上下文、预算、批准状态。然后,网关评估实际操作。这与将智能体置于静态允许工具列表之后的架构非常不同。工具列表回答了智能体可以访问什么。运行时决策回答了它现在实际能执行什么。生产环境中的非确定性智能体会影响财务,并可能做出影响公司和产品稳定性和声誉的决策。审计师和利益相关者不关心你的智能体如何决定在2026年底将NFT市场过度资本化200%。在分析你的智能体的工具时,你是否检查它现在是否应该执行给定工具——考虑当前参数、先前会话状态和预算限制——以及它是否进入了无限循环,以及当前LLM调用如何与策略对齐?
相似文章
谁授予了你的AI代理权限?
讨论AI代理工作流中的安全漏洞,即代理在关键步骤中假设存在人类监督,并提出了一个运行时控制平面,用于强制执行权限,并在破坏性操作前要求人工批准,通过Tandem演示进行了说明。
AI 代理不是用户,那么我们为什么给它用户凭证?
本文质疑为 AI 代理授予用户凭证的做法,并提出一个更细粒度的身份系统,以提高生产环境中的安全性和问责性。
在什么情况下你不再信任具有直接API访问权限的AI代理?
这篇文章探讨了何时信任具有直接API访问权限的AI代理,讨论了权限模型、用户继承以及企业工具中破坏性操作的审批步骤。
你们在生产环境中如何处理AI代理工具调用的授权?
本文讨论了在生产环境中处理AI代理工具调用授权所面临的挑战,包括上下文漂移和多轮不一致等问题,并请求社区对有效的架构模式提供反馈。
AI Agents 正在删除数据库。你会使用 "Policy-as-Code" 网关来阻止它们吗?
文章强调了 AI agents 执行破坏性操作(如删除数据库)的风险,并提出了一种运行时策略网关,该网关使用 Policy-as-Code 实时拦截和阻止不合规的 agent 行为,并询问用户是否会采用此类安全工具。