Claude Tag 的 Agent Identity 权限模型解读

本文是对官方文章「Agent identity in Claude Tag: a new access model for autonomous, team-wide AI」的中文要点摘要，完整内容以原文为准：https://claude.com/blog/agent-identity-access-model

为什么「代表用户行事」的模式会失效

传统的权限模型假设「一个人配一个助手」，让 agent 借用该用户的权限行动。但这个假设在两个趋势下站不住：

• agent 自主性在增长：agent 能独立完成的任务时长大约每四个月翻倍，已经可以在用户下线后自主安排并执行后续工作，不再局限于单次会话。
• 团队场景是多人共享的：Claude Tag 中 Claude 常驻在一个频道里，同时面对频道中的多个成员，不存在可以「代表」的单一用户。

Claude 以自己的身份行动

Claude Tag 的解法是让 Claude 不借用任何个人凭证，而是在它接触的每个系统里都拥有自己的账户——比如在 Slack 里以 Claude App 的身份发帖，在 GitHub 里以 Claude GitHub App 的身份开 PR，底层对应的是各系统里的服务账户（service account）。这样一来，共享频道就不会变成访问某个人私有文档的「后门」。

权限继承：workspace → 频道

管理员在工作区（workspace）层级设定一个基线的 agent 身份，新频道默认继承它；需要时可以在频道级别覆盖。可配置的要素包括：

例如可以只给工程频道开放 GitHub 与数据仓库访问，把 CRM 连接器限定在某个私有频道内。

Agent Identity 模型的核心变化

这套模型把权限判断标准从「这个用户能做什么」换成了「这个 agent 在这个隔离区（频道）里能做什么」。官方举例：一个对某仓库本身没有访问权的频道成员，只要该频道的 profile 已授权 Claude 读取这个仓库，他就可以让 Claude 帮忙读取——权限跟着频道走，而不是跟着人走。

身份边界：公开频道 vs 私有频道

• 公开频道共享同一个工作区级身份。
• 每个私有频道都有独立的身份，「Claude 在法务频道里学到的东西，不会出现在更广的工作区里」；同样，法务频道里的 Claude 身份也碰不到没在该频道被授权的代码。
• Enterprise 计划支持基于角色的访问控制（RBAC），管理员可以决定谁能在什么范围内调用 Claude。

默认给宽权限，再按需收紧

官方建议初期给 Claude 较为宽泛的工具与上下文访问权限，理由是「每接入一个系统，都会让其他已接入的系统更有用」——因为 Claude 能跨系统组合上下文。做法是：先从一个基线配置起步，观察操作日志（audit log），再按实际需要扩大或收紧权限；必要时也可以在特定频道彻底禁用 Claude，或叠加 RBAC 限制。

私聊（DM）走另一套机制

直接私信 Claude 时，走的是完全不同的路径：运行在用户自己的 claude.ai 账号下，使用用户本人的连接器、凭证与身份。这适合处理不该进入团队频道的任务或工具，比如起草私人邮件，或者只有该用户本人持有许可证的软件。

安全与审计

• 管理员为频道添加连接器时，凭证会被单独存储，并映射到对应的频道身份，在请求发出的网络边界处按需注入。
• 访问未被授权的主机（host）的出站流量会被直接拦截。
• 每一次 routine 执行、每一次 memory 写入、每一次用 agent 凭证发出的网络调用都会被记录；由于 Claude 使用的是各系统里真实的服务账户，这些操作同时也会出现在每个被连接系统自身的日志里，便于交叉核对。

后续计划

官方提到未来会加入：

• just-in-time credential grants（即时凭证授权）：让用户可以针对某个敏感操作在当下临时批准，而不必永久性扩大权限范围。
• 面向复杂权限结构的身份感知覆盖层（identity-aware overlay）。