Claude Tag 中的智能体身份：面向自主、团队范围的 AI 全新访问模型
英文标题：Agent identity in Claude Tag: a new access model for autonomous, team-wide AI
Anthropic 在 Claude Tag 中提出“智能体身份”模型，让 Claude 以独立服务账号接入工作区内的工具（如 GitHub、Slack、数据仓库），解决了多成员协作环境下“以用户身份执行”导致的权限模糊与安全风险。新模型以频道为边界继承或覆盖管理员配置的凭据与技能，所有操作均记录在智能体自有账号的审计日志中，并支持基于角色的访问控制。这对企业团队引入自主 AI 代理时的访问治理与安全扩展具有重要参考意义。
8.5 KB
321.9 KB
403 B
27.9 KB
13.6 KB
8.1 KB
9.5 KB
49.3 KB
中文
为了让 AI 智能体在人–智能体团队中发挥最佳作用，它需要能访问人类所拥有的相同工具、文档和上下文。
在“单人”AI 体验中（一个人与一个助手聊天），这很直接：你连接自己的账户，智能体代表你执行操作。但在像 Claude Tag 这样的“多人”AI 体验中，Claude 同时与许多人一起存在于共享频道中，它依赖的是属于工作区的工具和上下文，而不是任何个人。
为了让多人体验运转，Claude 需要拥有这些工具的独立账号，由管理员设置并绑定到工作区。我们把这种访问模型称为**智能体身份**。
在这篇文章中，我们将解释智能体身份是如何工作的，它如何将权限从“按用户”转移到“按频道”，以及如何在你自己的工作区中良好地划定其范围。
VIDEO
“以用户身份执行”为何会失效
当你把 AI 作为个人助手使用时，你可以连接 Google Drive、GitHub 和日历等平台，让模型使用你的访问权限来读写内容。
这种模型对 Claude Tag 并不适用，原因有两个：
-
智能体自主性在增强。 AI 智能体能够独立可靠完成的任务长度，大约每四个月翻一番。智能体现在可以为自己安排稍后执行的任务，并在发出请求的人早已下线后对事件做出响应。虽然用户可以设置在某些情境下触发智能体行动的例程，但智能体在很大程度上是自主工作的。
-
多人团队。 Claude Tag 将 Claude 放置在团队已经在协作的共享空间中——例如，三位工程师和一位产品经理正在一起调试的频道。但当有多个人在操控时，应该适用谁的权限？没有一个单一的人选能在所有时候都是正确的。这让管理员能够独立于所涉及的人员来定义智能体在 Slack 中能做什么，并能清晰地追踪在 Slack 中完成的操作。
Claude 以自身身份执行
在启用了 Claude Tag 的频道中，Claude 不是代表某个单一用户来执行操作。它在每个所接触的系统中都拥有自己的账号：它以 Claude 应用的身份在 Slack 中发布消息，以 Claude GitHub App 的身份打开拉取请求，并通过管理员供应的服务账号查询你的数据仓库。
由于没有个人用户凭据参与其中，共享频道永远不可能成为窥探某人私有文档的侧门。
继承权限
在智能体身份模型中，管理员在工作区层面定义一种身份——Claude 在所有地方所持有的连接和技能的基础集合——每个频道默认都继承它。然后，在适当的时候，他们可以在频道层面进行覆盖，例如授予工程频道访问 GitHub 和数据仓库的权限，或者将某个 CRM 连接限制在一个私密频道内。
除了凭据，管理员还可以定义：
- 仓库访问： Claude 可以读写哪些代码仓库。
- 连接器： Claude 完成工作所使用的工具和 API 密钥。在一个组织内，不同的 API 密钥可以以不同的权限级别连接到同一项服务（例如，Claude 可能在通用频道中被授予仓库只读权限，在数据团队的私有频道中被授予写入权限）。
- 技能与插件： Claude 为改善特定任务表现而动态加载的指令、脚本和资源文件夹。
- 常驻指令： 针对每个频道的自定义指令和上下文。
由于这一模型围绕 Claude 的不同身份构建，撤销某个身份就意味着在该身份被使用的所有地方终止了 Claude 的访问权限。相比在几十个用户账户中逐一审计智能体的单项操作，这管理起来要省力得多。
智能体身份模型如何运作
智能体身份用“这个智能体在这个隔离区内能做什么？”替代了“这个用户能做什么？”的问题。这与基于单一用户的访问控制列表（ACL）完全不同：这意味着，如果频道的配置文件授予了 Claude 读取某个仓库的权限，那么即便没有该仓库直接访问权限的频道成员，也可以要求 Claude 去读取该仓库。
这听起来很不同寻常，但我们认为，这是迈向适应自主、多人智能体的访问模型的必要一步。下面，我们勾勒一下如何思考那些边界的设定。
身份边界如何运作
Claude Tag 为每个私有频道创建一个独立的身份；工作区中的公开频道共享一个工作区级别的身份。Claude 在法律频道中的身份无法触及未被授权给该频道代码，它在工程频道中的身份也无法读取未被授权给该频道的法律文件。记忆和访问都遵守这些边界：Claude 在私有频道中学到的内容永远不会出现在更广泛的工作区中。
身份属于频道，因此频道中的任何人都可以默认 @ Claude，管理员可以将每个频道的配置文件范围限制到权限最低的成员。在 Enterprise 方案中，基于角色的访问控制可以让管理员走得更远，决定哪些成员能调用 Claude，这样一个频道既约束了智能体能接触的范围，也约束了谁可以发起请求。
对工具和上下文的广泛默认访问
团队如何在 Claude Tag 中划定 Claude 的工具访问范围：广泛的、低风险的集成在共享频道中以智能体身份运行，而个人或团队特定的工具则留在私信（DM）中，以用户身份运行。
通过在 Anthropic 内部运行 Claude Tag，我们发现，它的价值随着工具和上下文访问的增加而复合增长。每个接入的系统都会让其他系统变得更有用，因为 Claude 可以将跨系统的上下文组合在一起——从 Slack 中提取一条讨论线索，从 Drive 中获取一份文档，从追踪器中拿出一个工单，以及从仓库中运行一条查询，形成一个任何单一工具都无法提供的答案。
从 Claude 中获得最大价值的团队是那些从一开始就给予它广泛访问权限，然后根据组织的管理偏好逐步收紧权限的团队。智能体身份为 Claude 提供了足够宽广的范围来完成有用的跨系统工作，同时边界足够坚固，确保访问权限绝不会传播到未被授权的地方。我们的建议是：先在少数几个频道中使用基线配置文件，阅读审计追踪，然后在工作证明有必要时逐项审慎地扩展访问授权。
对于要求更细粒度的组织，管理员可以在特定频道中禁用 Claude Tag。管理员还可以应用基于角色的访问控制（RBAC），将 Claude Tag 的使用限制到特定用户。
私信
使用 Claude Tag 时，私信的工作方式与共享频道不同。私信运行在用户各自的 claude.ai 账户上——使用他们的连接器、凭据，并在结果上署上他们的名字。这使私信成为与 Claude 处理那些永远不应出现在频道中的任务和工具的理想场所，比如邮件草稿或只有你拥有许可证的软件。
安全与审计
当管理员将某个连接添加到频道的配置文件中时，凭据会被独立存储并映射到该频道的身份，然后在请求时被注入到网络边界。发往任何管理员未允许的主机的出站流量都将被彻底阻断。在审计方面，每一次例行任务、记忆写入以及使用智能体凭据发出的网络调用都会被记录下来，而且由于 Claude 是在自己的服务账号下执行操作，这些动作也会出现在每个所连接系统自己的日志中。
未来展望
智能体身份是 Claude Tag 访问模型的基础。未来，我们计划加强 Claude Tag 的安全能力，包括即时凭据授权——让用户能够在当下批准单一敏感操作，而不必永久扩大智能体的权限范围——以及为拥有更复杂权限结构的组织提供身份感知叠加层。这将在智能体权限之上增加用户级别的检查，使得 Claude 只有在频道配置文件和请求用户自身权限都允许时才执行操作。
在 Claude Tag 等产品中，从单人 AI 到多人 AI 的转变，让长期、基于团队的工作成为可能。智能体身份确保 Claude 对工具的访问足够广泛以发挥作用，同时足够受限以在企业规模上保持安全。
了解更多 关于 Claude Tag。
本文由 Claude Code 团队技术成员 Noah Zweben 撰写。
English / 原文
For an AI agent to do its best work on a human-agent team, it needs access to the same tools, documents, and context humans have.
In a “single player” AI experience (where one person chats with one assistant), that’s straightforward: you connect your own accounts and the agent acts on your behalf. But in a “multiplayer” AI experience like Claude Tag, Claude sits in a shared channel alongside many people at once, and it draws on the tools and context that belong to the workspace , rather than any one individual.
To make multiplayer experiences work, Claude needs its own accounts for those tools, set up by an admin and tied to the workspace. We call this access model agent identity.
In this post, we explain how agent identity works, how it moves permissions from per-user to per-channel, and how to scope it well in your own workspace.
VIDEO
Why “act as the user” breaks down
When you use AI as a personal assistant, you can connect platforms like Google Drive, GitHub, and your calendar, and let the model use your access permissions to read and write in them.
This model doesn’t work for Claude Tag for two reasons:
-
Increasing agent autonomy. The length of a task that an AI agent can reliably complete on its own has been doubling roughly every four months. Agents now schedule their own tasks for later and respond to events long after the person who asked has logged off. While users set up routines that trigger them to act given certain situations, the agent works largely autonomously.
-
Multiplayer teams. Claude Tag places Claude in shared spaces where teams are already working—e.g., a channel where three engineers and a PM are debugging together. But when more than one person is steering, whose permissions apply? There’s no single choice of person that’d be right all of the time. This gives admins the ability to define what an agent can do in Slack independent from the humans involved, and a distinct tracking of what is done in Slack.
Claude acts as itself
In a channel where Claude Tag is active, Claude isn’t acting on behalf of a single user. It has its own account in each system it touches: it posts in Slack as the Claude app, opens pull requests as the Claude GitHub App, and queries your warehouse under a service account provisioned by an admin.
And because there are no personal user credentials in play, a shared channel can never become a side door into someone’s private documents.
Inheriting permissions
In the agent identity model, admins define an identity—the baseline set of connections and skills Claude holds everywhere—at the workspace level, and every channel inherits it by default. Then, where it makes sense, they can override it at the channel level, such as by granting the engineering channel access to GitHub and the data warehouse, or confining a CRM connection to a single private channel.
In addition to credentials, admins also define:
- Repository access: which repos Claude can read and write to.
- Connectors: the tools and API keys that Claude uses to do its job. Across an organization, different API keys can connect to the same service at different permission levels (e.g., Claude might be given read-only warehouse access in a general channel, and write access in the data team’s private one).
- Skills and plugins: folders of instructions, scripts, and resources Claude loads dynamically to improve performance on specialized tasks.
- Standing instructions: custom instructions and context for each channel.
Because this model works around distinct Claude identities, revoking the identity ends Claude’s access everywhere that the identity was used. This takes much less effort to manage than auditing individual agent actions across dozens of user accounts.
How the agent identity model works
Agent identity replaces the question “what can this user do?” with “what can this agent do in this compartment?” That’s a departure from per-user Access Control Lists: it means that a channel member without direct access to the repo can ask Claude to read that repo, if the channel’s profile grants Claude that permission.
This is unusual, but we think it is a necessary step toward an access model that works for autonomous, multiplayer agents. Below, we sketch out how to think about setting those boundaries.
How identity boundaries work
Claude Tag creates a distinct identity for each private channel; public channels in a workspace share a workspace-level identity. Claude's identity in a legal channel can't reach code that wasn't granted there, and its identity in an engineering channel can't read legal documents that weren't granted there. Memory and access respect those boundaries: what Claude learns in a private channel never appears in the wider workspace.
The identity belongs to the channel, so anyone in it can tag Claude by default, and admins can scope each channel's profile to the least-privileged member. On Enterprise plans, role-based access control lets admins go further and decide which members can invoke Claude at all, so a channel governs both what the agent can reach and who can ask.
Broad default access to tools and context
How teams scope Claude's tool access in Claude Tag: broad, low-risk integrations run in shared channels under an agent identity, while personal or team-specific tools stay in DMs and run as the user.
Running Claude Tag inside Anthropic, we found that its value compounds with tool and context access. Each connected system makes every other one more useful, because Claude can combine context across them—pulling a thread from Slack, a doc from Drive, a ticket from a tracker, and a query from a warehouse into one answer that no single tool could provide.
The teams that get the most out of Claude are the ones that grant it generous access from the start, and pare access back depending on their organization’s admin preferences. Agent identity gives admins broad enough scope for Claude to do useful cross-system work, with boundaries firm enough that the access never travels somewhere it wasn’t granted. Our advice is to start with a baseline profile in a few channels, read the audit trail, and then extend access where the work justifies it, one deliberate grant at a time.
For organizations that require even more granularity, admins can disable Claude Tag in specific channels. Admins can also apply role-based access controls (RBAC) to limit access to Claude Tag to specific users.
Direct messages
With Claude Tag, direct messages work differently than in shared channels. DMs run on users’ individual claude.ai accounts—their connectors, credentials, and name on the result. This makes DMs the right place to work with Claude on tasks and with tools that should never live in a channel, like email drafts or software only you have a license for.
Security and audit
When an admin adds a connection to a channel's profile, the credential is stored independently and mapped to that channel's identity, then injected at the network boundary at request time. Outbound traffic to any host an admin hasn't allowed is blocked outright. On the audit side, every routine, memory write, and network call made with agent credentials is recorded, and because Claude acts under its own service accounts, those actions also land in each connected system's own logs.
What’s next
Agent identity is the foundation of Claude Tag's access model. In the future, we plan to strengthen our Claude Tag’s security offerings to include just-in-time credential grants—so that a user can approve a single sensitive action in the moment without permanently widening the agent's scope—and an identity-aware overlay for organizations with more complex clearance structures. This will add user-level checks on top of an agent’s scope, so Claude only acts when both the channel's profile and the requesting user's own permissions allow it.
The shift from single player to multiplayer AI in products like Claude Tag makes long-running, team-based work possible. Agent identity ensures that Claude’s access to tools is broad enough to be useful, but scoped enough to be secure at enterprise scale.
Learn moreabout Claude Tag.
This article was written by Noah Zweben, a member of technical staff on the Claude Code team.