Claude Tag Gives AI Its Own Identity in Slack

Here's a permissions problem that nobody had to solve until very recently: when an AI agent sits in a Slack channel with five people, all asking it to do things, whose credentials does it use?

It sounds like a detail. It isn't.

This is the question Anthropic's product team says they had to work through when building Claude Tag, a feature that drops Claude directly into Slack as a persistent team collaborator. Noah, the product manager who walked through the design in a video published this week, frames the problem cleanly: "When you put Claude in a channel with five people, 'act as a user' stops making sense. Whose permissions apply? The last person who tagged Claude? The least privileged?"

Neither answer is good. And the problem gets worse when the agent operates without any human in the loop at all—synthesizing a code change from several filed issues and a monitoring alert that came in at 3 a.m., when nobody asked for anything. There's no requesting user to borrow credentials from. You either give the agent standing access or you don't, and if you do, you'd better be intentional about what that access actually covers.

Anthropic's answer is to give Claude its own identity.

What "Acting as Itself" Actually Means

The concept is straightforward in principle: Claude Tag has its own account and service keys in your connected systems. It doesn't impersonate any of your team members. Its access doesn't fluctuate based on who's in the thread or who tagged it last. As Noah puts it, "what it can reach in a channel never changes based on who asked—it's predictable for users and legible for security teams."

Legibility is worth pausing on. Security teams have a hard enough time auditing what humans do with access. A system where an AI agent's effective permissions are a function of which user triggered it last is a forensic nightmare. If Claude touches your data warehouse at 2 a.m. and something goes wrong, you want an audit trail that says "Claude Tag accessed X with credential Y under scope Z"—not "well, it inherited permissions from the last five people who talked to it."

The architecture Anthropic landed on has three tiers, each designed around a different risk tolerance.

The workspace baseline. When admins set up Claude Tag, they create an "access bundle"—a named collection of connections, repository access, skills, and standing instructions—and attach it to the whole Slack workspace. This is the floor: what Claude can do anywhere in the organization. Noah's framing here is useful: "Think about it as the access you'd be comfortable with truly any member of the workspace having." If you wouldn't give a new hire access to something on day one, it probably shouldn't be in your workspace baseline. The credential in that bundle isn't anyone's personal API key—it's one created specifically for Claude, scoped at the provider side to exactly what the admin wants the agent to read.

Channel step-ups. Some teams need more. The data team working with a warehouse, the engineering team with production access, a security channel with elevated system visibility. Admins can create a second access bundle and attach it to a specific private channel. That credential lives only there. Tag Claude in the engineering channel and it can reach the warehouse; tag it in the general channel and it can't. "The channel is the boundary," as Noah describes it—and that boundary holds regardless of who's asking.

Direct messages. This is where the model gets interesting. In a DM, Claude Tag runs under your personal Claude AI account, your own connections and credentials. The distinction Noah draws is memorable: "In the channel, think about Claude as a general teammate. In a DM, it's your personal assistant with all of your own tools." Sensitive categories—recruiting software, compensation data, personnel files—belong here, not in shared channels where the workspace baseline or even a channel step-up might be too broad.

Why This Matters Beyond Slack

The identity problem Claude Tag is solving isn't Slack-specific. It's the fundamental challenge of deploying agents in any multi-user environment where the agent operates with some degree of autonomy. The old model—where an AI tool does things on behalf of whoever is currently logged in—collapses the moment the agent acts without being directly invoked, or when multiple people invoke it for overlapping purposes.

Anthropic isn't alone in grappling with this. The permission problem surfaces differently but persistently across AI products: how do you give an agent enough access to be genuinely useful without making that access either too narrow to work or too broad to audit? Claude Tag's approach—dedicated agent credentials, admin-governed scopes, channel-level boundaries—is one answer. It trades some flexibility for predictability, which is usually the right call when you're talking about systems that can write code, read sensitive data, or take actions at 3 a.m. when no human is watching.

The "set it up once and your whole team benefits" pitch also deserves scrutiny, not because it's wrong, but because "set it up once" depends entirely on how carefully the initial setup is done. An admin who provisions the workspace baseline too liberally—throwing in access to systems that feel benign but carry sensitive data—doesn't create a security problem immediately visible in any dashboard. It creates one that surfaces later, in an audit, or after an incident.

The model also assumes admins have a clear picture of what each team genuinely needs. In practice, organizations often don't. Access creep in human systems is well-documented; there's no structural reason it won't happen in agent systems too, especially when adding access is as easy as editing an access bundle. The architecture supports least-privilege—it doesn't enforce it.

What Security Teams Should Actually Evaluate

If your organization is considering Claude Tag, or any similar AI agent integration, the technical questions worth asking go beyond the basics of OAuth scopes and credential rotation.

First: does the agent's identity have a clear, auditable paper trail across every system it touches? "Claude Tag accessed the data warehouse" needs to be something you can actually see in your warehouse logs, not just in Anthropic's audit interface.

Second: what happens to access bundles when team membership changes? If the data team's private channel gets a new member who shouldn't have influenced Claude's access there, does anything change? It shouldn't, under this model—but verifying that the channel boundary actually holds under various conditions is worth testing.

Third: the DM channel is where things get complex from an organizational standpoint. If Claude is running under an individual's credentials in a DM, any actions it takes there may be indistinguishable from actions that person took directly. That's not a flaw unique to Claude Tag, but it's worth thinking through before deploying in regulated environments.

None of this is an argument against the approach. Dedicated agent identity is, in my assessment, clearly better than the alternative of borrowed user credentials in a multi-actor environment. The design choices Anthropic describes—scoped credentials, admin governance, channel-level isolation—reflect a genuine engagement with how access control actually works in enterprise security, not just a feature checklist.

The harder question is whether organizations deploying these tools will govern them with the same rigor they'd apply to a new human hire. An AI agent with standing access to your production systems is, from a security surface standpoint, a service account. Most organizations have a complicated relationship with service account hygiene already.

Claude Tag is a well-designed access model handed to organizations that may or may not operate it well. That gap—between what a system allows and what teams actually do—is where most enterprise security incidents live.