Agent identity is Claude Tag's real security boundary
2026/6/25 · 10:42

Agent identity is Claude Tag's real security boundary

Anthropic's Claude Tag access model treats Claude as a channel-scoped service account rather than a borrowed user, shifting enterprise agent governance from individual permissions to admin-provisioned identities, proxy-controlled egress, and auditable compartments.

リサーチノート

Claude Tag's important security move is easy to miss because it sounds like an admin detail. On June 24, Anthropic published the access model behind Claude Tag: in shared Slack channels, Claude does not borrow the credentials of the person who tags it. It acts through its own channel- or workspace-scoped identity, provisioned by an administrator and mapped to specific tools, repositories, skills, instructions, and memories.1
That is the real product bet. Claude Tag may look like a Slack bot, but agent identity turns it into a governed actor inside the enterprise graph. The model is useful precisely because it breaks with the usual personal-assistant pattern: instead of asking "what can this user do?" it asks "what can this agent do in this compartment?"2

The old permission model breaks in multiplayer work

A personal AI assistant can act as you because the work is one-to-one. You connect your Drive, GitHub, calendar, or internal systems, and the model uses your permissions. That is coherent when the output is private to you and the model's action should be attributed to you.
Claude Tag changes the surface. The launch post describes Claude as a team member in Slack: teams grant it selected channels, tools, data, and codebases; anyone in the channel can tag @Claude; Claude can remember relevant channel information, plan future tasks, and work asynchronously over hours or days.3 In that setting, there is no clean answer to whose permissions should apply.
Anthropic's agent-identity post makes the problem explicit. If three engineers and a product manager steer Claude in the same debugging channel, no single human account is the right permission source all the time.1 A user-scoped model also creates a bad failure mode: a shared channel could accidentally become a side door into one person's private documents.

The new unit of access is the channel

In Claude Tag channels, Claude acts as itself. Anthropic says it posts in Slack as the Claude app, opens pull requests as the Claude GitHub App, and queries other systems under service accounts provisioned by an admin.1 The docs state the same boundary more operationally: channel sessions use the agent's service accounts, while direct messages run on the individual user's claude.ai account and personal connectors.2
That separation produces four practical rules:
SurfaceWhose access appliesWho can see the workWhat it is best for
Slack channelThe channel's connections, set by an adminEveryone in the channelShared work the team should inspect or continue4
Direct messageThe user's own claude.ai connectorsThe userPersonal tasks using personal data4
Claude Code in SlackThe requester's Claude account and GitHub connectionThe requester-facing Claude Code flowCoding work attributed to the requester, not a Claude Tag channel identity2
The consequence is intentionally strange: someone in a channel may be able to ask Claude to read a repository they personally cannot access, if the channel's profile grants Claude that access.1 That is not a bug in the model. It is the model. The control point moves from individual ACLs to channel membership, channel scope, and the admin-provisioned access bundle.
Agent access scoping diagram
Anthropic's scoping diagram distinguishes low-risk shared tools from personal or sensitive tools that should stay in DMs.1

The security boundary is Agent Proxy

The strongest part of the design is not that Claude has a named identity. It is where credentials live.
According to Anthropic's documentation, a channel task starts in Slack, runs in an ephemeral sandbox hosted by Anthropic, and reaches outside systems only through Agent Proxy.2 The sandbox itself holds no credentials. When Claude needs to call GitHub, a warehouse, or another HTTP API, Agent Proxy checks the destination against admin rules, retrieves the matching credential from a separate credential store, and injects it at the network boundary.2
Claude Tag request path
Claude Tag routes outbound requests through Agent Proxy; credentials are injected at the boundary, not placed inside the sandbox.2
The proxy has three outcomes. If the host matches a connection rule, the request proceeds with that credential. If it only matches an allowlist, it proceeds without a credential. If it matches neither, the request is blocked.5 This matters because it gives enterprises a hard egress boundary rather than a prompt-level promise.
Agent Proxy decision branches
The proxy decision path makes the default-deny branch explicit: an unlisted host is blocked, not merely reached without credentials.5
The same page adds two operational details that security teams will care about. First, credentials are write-only after setup and can be narrowed to hosts, path prefixes, or read-only methods.5 Second, actions in connected tools appear under Claude's service accounts, which means revocation and audit can happen at the agent account layer instead of across many human accounts.5

The trade-off is group delegation

Agent identity solves one governance problem by creating another. It prevents a shared channel from borrowing a user's private credentials, but it also means the channel is now a delegation boundary. If a connection is attached to #platform-eng, every eligible person in that channel can ask Claude to use it.
That is why the useful admin question is no longer "which employee has access?" It is "which rooms are allowed to contain an agent with this reach?" Claude Tag's own docs make this visible: access follows the channel, not the person, and the fastest way for a user to know what Claude can reach is to ask @Claude what can you access from this channel?4
This is a good fit for work that should be shared. Incident triage, launch-status synthesis, data pulls, backlog cleanup, and draft pull requests all benefit when the whole team sees the same working thread.6 It is a worse fit for personal inboxes, licensed tools tied to one person, or anything where the requester, not the channel, should carry accountability. Anthropic's own guidance sends those tasks to DMs, where Claude runs under the user's own account.1

What to watch next

Anthropic says it plans to add just-in-time credential grants, so a user can approve a single sensitive action without permanently widening the agent's scope. It also points to an identity-aware overlay where Claude acts only when both the channel profile and the requesting user's own permissions allow it.1
Those two planned features are the right pressure points. The current model is cleanest when the channel's purpose, membership, access bundle, and audit owner all line up. Real companies are messier. A Slack channel often mixes people from different functions, and a task can cross from low-risk reading into high-risk writing halfway through the thread.
So the test for Claude Tag is not whether a service-account model is conceptually elegant. It is whether administrators can keep channel scopes legible as the number of agents, scheduled routines, memories, plugins, and connected tools grows. Agent identity gives Anthropic a serious answer to the "whose credentials?" problem. The next question is whether enterprise teams can keep the answer understandable after Claude becomes a standing participant in dozens of rooms.

関連コンテンツ

このコンテンツについて、さらに観点や背景を補足しましょう。

  • ログインするとコメントできます。