北京
最初，它只是帮你读日志、总结工单、给个部署建议。一切看上去都很安全，毕竟就多一个辅助输入而已。但没过多久，事情就开始“膨胀”——AI代理被拉着去更新工单状态、发起部署请求、重启 worker，甚至直接查询运维系统深处那些从来不对外开放的接口。这个时候，它已经不是一个聊天机器人了，它变成了一个实实在在的执行面。
很多团队到了这一步，仍然把所有精力都投在提示词工程上。提示词当然重要，但它已经不是最强的控制点了。一旦代理通过工具动起手来，工具访问就等同于生产访问。你不可能再靠几句自然语言描述来守住安全底线。
到底应该由谁来回答这些问题：谁在请求这次工具调用？工具是不是已经被注册并且有意暴露出来的？有没有一条不可被绕过的策略把它拦住？调用者的角色有没有对应的权限范围？参数是否合法？这个动作是只读、可逆、高风险还是破坏性的？需不需要人工审批？系统自己能不能原生的把整个过程审计留痕？当你把这些列在一张表上，你会发现，仅靠大模型理解工具描述来决定是否调用，太软了，根本没法上生产。
最容易被误用的就是工具描述。它只是帮模型判断“这件事该不该用这个工具”，从来不是一个权限边界。打个比方，一个叫 infra_tool 的东西，描述里写着“帮助检查和运维基础设施”。对本地 demo 来说够用，但一到生产环境就崩了。“运维”到底是读日志、重启一个 worker、发起部署，还是直接删资源？而且每次操作到底授权给谁？单凭一句模糊描述，等于把大门钥匙交给了猜谜语的人。
安全的设计必须把工具选择和授权彻底解耦。模型可以提议调用某个工具，但最终是否放行，是由一套确定性的策略层说了算。一个最小可用的架构大致就是这样：代理的请求先经过可信的注册表查询，同时捞到风险元数据；然后硬碰硬地被静态风险策略挡一次；接着做角色与权限范围的匹配；再严格校验参数；需要人工拍板的就走审批关卡；最后才轮到真正的工具执行，而且每一步都原原本本写进审计日志。关键的一点是，代理从来不直接调工具，它只是发起一次调用请求，治理层才握有最终执行的决定权。
这个模式并不复杂，甚至有离线参考实现放在 GitHub 上。它用一个确定性的 Python 包完成一件很窄但很明确的事：在真正执行前，把不安全的路径直接卡死。比如最底层的角色权限映射，看起来甚至有点“无聊”：“viewer”只能读日志，“operator”额外能请求重启 worker，“admin”再加一个部署请求的能力。但正是这种毫无脑筋急转弯的硬映射，才让每一次工具调用都有确切归属，而不是让模型靠文字描述去揣测自己能干什么。
当角色、范围和破坏性动作被明确挂在代码里，而不是藏在提示词的措辞里，你才真的开始回答最初那个问题：到底什么时候，AI代理需要权限边界？答案是：从它第一次被允许调用工具的那一刻起。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
