安全透视 | 智能体权限：当AI拥有了操作能力
AI智能体正在从“回答问题”走向“替人办事”。
过去多数组织使用AI的方式是输入问题、得到答案，AI输出文字或代码，最终由人去执行。如今，被赋予工具调用能力的智能体，已经可以在缺少逐步人工确认的情况下，自主完成从读取信息到执行动作的闭环。效率提升的同时，一个新的治理命题也随之而来：当AI真正拥有了操作能力，权限该怎样配置、怎样管理。
现象：AI从“动口”到“动手”
过去，组织里用的AI大多是“对话式”的。提问、生成、参考，AI给出结果，人来做决定、去执行。
智能体改变了这一点。一个具备工具调用能力的智能体，能够读取文件、发起请求、调用接口、操作业务系统。从辅助决策到自主执行，AI在组织中的角色发生了实质变化。
这种变化本身是在提效，但如果管理思路还停留在“对话工具”阶段，就容易接不住随之而来的风险。
变化：和企业外部的插件不是一回事
上篇我们讨论了外部模型和第三方插件的接入风险，核心是“管入口”，防止不该接的接进来。本文聚焦企业内部在用的智能体，可能是自建的，也可能是基于通用模型二次开发的。
两者治理重点不同：外部模型和插件侧重供应链与接入安全，内部智能体侧重运行时行为治理。
一句话，插件关注“能不能接入”，智能体关注“接入后能执行哪些操作”。边界分清楚，后面的治理才好展开。
风险：问题往往藏在“看不见的操作”里
权限给得粗放，意味着智能体拿到的操作权限超出了实际所需，由此产生的风险，与外部攻击并不相同：攻击通常来势明显、易于识别，而粗放授权带来的问题，往往藏在日常已获授权的操作之中，不易第一时间察觉。一封本不该发出的邮件、一项本不该修改的配置、一条本不该读取的记录，都可能在自动执行中变成现实。
更麻烦的是，智能体的动作常常由一连串自动决策驱动，等事后想要复盘，才发现“原来当时它做了这个”。若缺少完整的调用日志与权限映射，影响形成之后，责任便难以追溯到某一次具体的调用。
路径：给权限、看权限、追权限
治理内部智能体，可以抓住三个动作。
给权限，坚持最小化。智能体需要什么权限就给什么，不默认授予全量。可参考RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）等权限模型，对业务系统、数据接口的调用按场景精确授权。工具调用层面，可借助 Function Calling 的权限声明或 MCP（模型上下文协议）的授权机制，明确每次调用的能力边界。
看权限，让操作可观测。每一次工具调用、每一条执行结果，都应被记录与回溯。日志应包含调用者（智能体ID）、输入、输出、时间、触发来源等字段，并可参照OpenTelemetry等规范记录调用链。操作留痕既是事后核查的基础，也是及时发现异常的前提。
追权限，让责任可界定。当某次操作引发问题，能够定位到是哪一次调用、由哪个智能体、在哪个环节触发，而不是笼统归为“AI干的”。这需要将调用日志与业务操作关联，支持从业务事件反查具体调用链。
对高风险操作——如发送邮件、修改配置、删除数据——应设置人工确认节点，避免全自主执行带来不可逆后果。多智能体协作时，权限可随任务传递，但不可无限继承，需设计委托边界，防止一个智能体的权限被另一个智能体放大使用。
智能体并非不能赋权，关键在于权限给得清楚、用得可见、出事可追。当评估真正融入日常运转，它才从一份合规报告，变成持续可见的风险水位线。
