AI代理何时需要权限边界？
内容提要
AI代理调用工具时，工具访问即生产访问，风险随权限扩大。需用确定性策略层分离工具选择与授权，通过静态风险策略、角色授权、参数验证和审批门控，阻止危险操作。代理仅请求调用，最终执行由治理层决定，并记录审计日志。模型提议，策略决策，确保安全。
延伸解读
工具描述不等于权限边界
文章强调，自然语言工具描述只帮助模型判断工具相关性，但绝不能作为权限边界。例如，一个名为 infra_tool 的工具描述为“帮助检查和管理基础设施”，但“管理”可能意味着读取日志、重启工作进程或删除资源。这种模糊性在生产环境中是危险的，因为模型可能误解描述而执行超出预期的操作。因此，必须将工具选择与授权分离，用确定性的策略层来定义和执行权限。
策略层的关键设计：失败关闭与审批门控
参考实现展示了策略层的核心原则：未知角色默认失败关闭（空权限集），破坏性工具直接禁用，高风险操作需要人工审批。审批门控必须绑定请求ID，防止通用令牌被重放。系统返回三种状态：允许、阻止、需要审批，其中“需要审批”是合法状态，表示调用者有权请求但需人工验证。这种设计避免了将审批流程简化为二元成功/失败，确保安全与合规。
审计日志：记录被阻止的尝试同样重要
文章指出，大多数系统只记录成功执行，但AI代理场景下，被阻止的调用往往提供最有价值的遥测数据。审计记录应包含阻止决策、审批请求和允许决策，以便安全团队重建代理的实际行为和尝试行为。同时，生产系统需对审计记录进行数据最小化处理，包括保留策略、脱敏、访问控制和防篡改，因为参数可能包含敏感信息。
权衡与局限：治理带来摩擦，但必要
该架构并非万能，不能防止提示注入、身份欺骗或合规失败，但它消除了代理对执行的最终决定权。代价是摩擦：严格模式需要维护、角色映射需明确归属、风险级别需定期审查、审批流程增加延迟。文章提醒，权限过大的工具演示更快，但生产风险隐藏其中。在连接代理到真实工具前，必须能回答关键问题，否则就是过早接入生产。
Q&A
为什么AI代理调用工具时风险会增加？
因为工具访问即生产访问，代理不再只是生成文本，而是能够执行实际操作，如更新工单、重启服务或查询内部系统，从而成为执行面，风险随权限扩大而增加。
AI代理的权限边界应该如何设计？
应该采用确定性策略层，将工具选择与授权分离。代理只请求调用工具，由治理层决定是否执行，并通过静态风险策略、角色授权、参数验证和审批门控来阻止危险操作。
为什么工具描述不能作为权限边界？
因为工具描述是自然语言，用于帮助模型判断工具相关性，但无法明确具体操作、授权角色和风险等级，例如“管理基础设施”可能包含多种操作，因此不能作为执行契约。
AI代理调用工具时，最小可行架构包含哪些步骤？
包括：代理请求、可信工具注册表查找和风险元数据、静态风险策略、角色/范围授权、严格参数验证、审批门控、工具执行器、审计日志。代理从不直接调用工具，只请求调用。
为什么参数验证很重要？
因为即使授权用户也可能传递无效参数，导致意外权限扩大。例如，read_logs工具接受service和limit，但若额外传入write字段，可能被下游代码解释为写操作，造成安全风险。严格模式验证可强制明确工程决策。
审批门控在AI代理工具调用中扮演什么角色？
审批门控是架构性组件，用于高风险或明确需要审批的操作。它必须绑定请求ID，防止通用令牌被重放。审批状态是有效工作流状态，表示调用者已授权、载荷有效，但执行仍需人工验证。
为什么审计日志对AI代理安全很重要？
因为审计日志不仅记录成功执行，还记录被阻止的调用和审批请求，帮助安全团队重建代理实际行为和尝试行为。同时需对敏感参数进行数据最小化处理，如保留、脱敏、访问控制和防篡改。
AI代理权限控制的主要权衡是什么？
主要权衡是摩擦：严格模式需要维护、角色映射需明确所有权、风险等级需定期审查、审批流程增加延迟、审计日志需保留策略。但宽松工具虽演示更快，却隐藏生产风险。
