给 Agent 增加工具时，我们经常只检查 schema 能不能调用、参数是否正确，却很少问：这个 Agent 为什么需要这项权限？

当工具只做搜索或计算时，这个疏忽不明显。一旦 Agent 能读取邮箱、访问网盘、修改文件、操作浏览器和预填平台内容，工具调用已经变成权限调用。

8 月 24 日，Google Cloud 的 Agent 安全治理文章把 AI Agent 称为会读取邮件、查询数据库和触发 API 的“内部人”。同日，Okta 宣布 Agent SSO 正式可用，强调 Agent 身份、最小权限、短期令牌和生命周期审计。8 月 25 日，Linux Foundation 公布的 Agent 技术会议议程也把信任边界、审批门与审计列为生产级 Agent 的核心问题。

这不是“企业安全部门才需要关心”的事。个人创作者和小团队一旦让 Agent 接触真实账号与业务资料，也会遇到同一个问题，只是规模更小。

1. 工具层和权限层必须分开建模

一个工具通常同时暴露四类能力：

维度	需要回答的问题	常见风险
身份	谁在调用，代表哪个岗位	所有任务共用一个宽权限身份
资料	它能读到哪些文件和记录	无关资料进入上下文或交付物
动作	它能读取、写入、删除还是对外发送	低风险读取与高风险写操作混在一起
审批	哪些动作必须停下来等人确认	自动化越过不可逆节点

MCP 或函数定义回答的是“怎么调用”，并不自动回答“这个岗位是否应该调用”。即使工具自身做了鉴权，给一个 Agent 同时挂载几十个工具，仍可能让路由错误和提示注入拥有更大的影响面。

因此，Agent 配置不应该只有 tools，至少还应有岗位、数据范围、动作级别和审批策略。

role: blog_publisher
data_scope:
  read:
    - brand-kit/**
    - content-review/**
  deny:
    - finance/**
    - contracts/**
actions:
  allow:
    - research
    - draft
    - upload_image
    - prefill
  approval_required:
    - public_publish
    - delete_post
    - switch_account
audit:
  record_inputs: true
  record_page_readback: true

这不是某种统一标准，只是一份设计示意。重点是把“能调用什么”和“允许做到哪一步”写成两个字段。

2. 先按岗位缩小权限，再设置人工审批

很多 Agent 系统只做第二步：凡是敏感动作都弹窗问用户。

问题在于，如果底层权限仍然很宽，用户每天会面对大量授权提示。确认次数多了，弹窗就会从安全机制变成肌肉记忆。

更合理的顺序是：

1. 先定义岗位目标；
2. 只挂载完成岗位所需的 Skill、MCP 和资料；
3. 把读取、生成、预填与发布、付款、删除分开；
4. 只在少数不可逆或对外动作前要求确认；
5. 动作完成后保留输入、选择结果和页面回读记录。

例如“公众号编辑”可以读取品牌资料、历史文章与图片，完成选题、写作、配图、排版和草稿预填。它不需要访问财务目录，也不应该默认拥有付款和批量删除权限。

“视频制作”可以调用脚本、分镜、配音和视频生成工具；“视频发布”则负责账号、封面、标题、声明与发布前检查。两个岗位能协作，但权限不必合并。

3. 一个可落地的动作分级

对小团队而言，可以先用三级动作表，不必一开始就引入复杂系统。

A 级：自动执行

• 读取指定资料；
• 搜索公开信息；
• 生成草稿和内部文件；
• 对产物做格式检查；
• 保存版本和运行记录。

B 级：执行后回读

• 移动或重命名工作目录内文件；
• 上传素材到指定草稿；
• 在已确认账号中预填内容；
• 更新非公开的数据表。

这类动作通常可逆，但系统应回读目标、数量和最终状态。

C 级：人工确认

• 公开发布或群发；
• 付款、下单和修改收款信息；
• 删除作品、文件或业务记录；
• 切换账号、扩大权限范围；
• 向外部人员发送消息。

判断标准不是“AI 有没有能力”，而是动作是否对外、是否不可逆、出错后影响是否难以控制。

4. 多 Agent 不只是分工，也是隔离

多 Agent 架构经常被宣传成“多个助手协作，所以效率更高”。另一个更实际的价值是权限隔离。

如果内容研究、文章写作、图片制作和平台发布是四个岗位，那么研究岗位不需要平台登录态，图片岗位不需要正文发布权限，发布岗位也不必读取全部公司资料。上游只把必要产物传给下游，而不是共享整个上下文与工具箱。

这种结构仍要处理 Agent 间传递的可信度、日志和错误恢复，不能因为“拆开了”就认为天然安全。但它至少让权限边界可见，也更容易定位一次错误到底发生在哪个岗位。

5. Tipkay 的产品取舍

这也是我们做 Tipkay 时选择岗位化 AI 的一个原因。每个 AI 员工聚焦一类交付任务，Skill 和 MCP 可以按助手配置；需要协作时，可以把垂类助手作为工具组合起来。官网目前明确写到，本地客户端使用素材和已登录平台，登录态留在本机，发布等关键动作由用户确认。

这里需要说清边界：这不等于绝对安全，也不是替代企业 IAM、平台风控或专业审计。它解决的是小团队最先遇到的一层问题——不要让写稿、做图、发布和财务共用一个没有边界的万能身份。

6. 十分钟权限体检清单

如果你的 Agent 已经装了很多工具，可以按下面的顺序检查：

• 导出全部工具和 MCP；
• 标记每项工具会读取、写入还是对外执行；
• 列出它默认可见的目录、账号与数据源；
• 圈出发布、删除、付款、外发和改权限；
• 将不属于同一岗位的能力拆开；
• 为高风险动作增加精确目标回读与人工确认；
• 检查日志能否回答“谁、在何时、用什么输入、做了什么”。

Agent 的成熟度，不应该只看它会调用多少工具。

更应该看它能否在刚好够用的权限里完成任务，并在该停下来的地方真正停下来。

参考资料：

• Google Cloud Agent 安全治理
• Okta Agent SSO
• Linux Foundation AGNTCon + MCPCon Japan
• Tipkay 官网

标签建议：人工智能、网络安全、软件工程、自动化、Agent