When Anthropic announced its agent identity access model for Claude Tag on June 24th, a peer asked me, “If Claude has its own identity in Slack, who exactly is being authorized when it acts?”
That’s a great question.
It’s easy to see why it feels that way. Someone tags Claude in Slack. Claude reads the thread. Claude replies conversationally and takes action. It may summarize a decision, open a ticket, update a document, check a repository, or query another system. That can feel like a teammate joined the channel and got to work.
But Claude is not a person with judgment, accountability, and independent intent. It is software. That distinction matters because IAM depends on clarity. Human users, service accounts, applications, and AI agents all need governance. But they do not carry the same accountability model.
The more human the interface feels, the easier it is to lose sight of the access path underneath it.
The Hotel Desk Analogy
Think about a hotel front desk.
With a person at the desk, we ask whether they verified the guest, checked the reservation, followed policy, and were authorized to issue the key. If they make a mistake or misuse access, there is a human decision-maker to review and hold accountable.
With a human-like video bot connected to the key card system, the exchange may feel similar to the customer. But from a governance view, there is no human judgment in the system issuing the key. Accountability has to be assigned around it: who approved the workflow, who granted the access, who can invoke it, who monitors it, and who is responsible when it does the wrong thing.
What Anthropic Is Actually Doing with Claude Tag
Anthropic’s model is designed for a shared, “multiplayer” AI experience. In a single-user assistant model, the AI can act through one person’s connected accounts. Claude Tag sits in Slack channels where multiple people may be steering the work.
That creates a hard IAM question: whose permissions should Claude use?
Anthropic’s answer is: Claude should not act as any one person in the channel. It should act as itself.
That means Claude can have its own identity in connected systems. Admins can define a baseline identity at the workspace level, then scope or override access at the channel level. A private engineering channel might grant Claude access to specific repositories. A legal channel might grant access to legal documents. A public channel might have only low-risk, read-only tools.
That is a reasonable design choice.
It is also a governance shift.
If the identity belongs to the channel, then channel membership starts to matter in a new way. A person may not have direct access to a repository, but they may be able to ask Claude to read it if Claude’s channel profile has that access.
The question expands beyond “Can this user access the system?” to “Can this user cause the agent to use its access?”
AI Agent Identity Joins an Already-Crowded Problem
Most organizations are already drowning in access they don’t fully control. Service accounts. API keys. OAuth grants. Bots. Forgotten secrets. Overprivileged automation. Accounts no one owns. Agent identity is just an additional issue to add to this list.
And sometimes the agent finds its own way in. In the PocketOS incident, a Claude-powered agent working on a routine task encountered a credential mismatch, found an unrelated API token, and used it to delete the production database, entirely on its own initiative. Nobody granted that access intentionally. The agent discovered it and acted on it.
The risk is not that Claude “becomes human.” The risk is that a human-like interface makes a software permission path feel informal, and informal doesn’t get audited. This doesn’t require a new category of tooling to solve. It requires treating Claude’s channel-scoped identity the way you’d treat any other service account: defined owner, documented scope, regular access review. The attack surface is new, the concept is not.
Why Slack Channels Are Now Part of Your IAM Surface
Slack makes this especially important.
Channels are collaboration spaces. They are not always managed like access-control groups. People get added for many reasons, including visibility, convenience, and executive awareness.
But if being in a channel means someone can cause an agent to access tools and repositories like GitHub, Google Drive, Jira, Salesforce, or internal runbooks, then channel membership has become part of identity and access governance in a new way.
The risky shortcut is, “Claude has access, so the action is allowed.”
The better test is narrower: is this person allowed to ask this agent, in this channel, to take this action in this system?
The Audit Trail Problem with Conversationally-Steered AI Agents
With a well-governed service account, an anomalous action should have a traceable chain: a ticket, config change, scheduled job, owner, or approval record. Something a responder can point to and say: that’s why it happened.
With a conversationally-steered agent, that chain gets murky. The prompt that triggered the action may have been ephemeral, like a Slack message that’s now buried or an inline comment in a document the agent read. The model interpreted it, acted on it, and the reasoning isn’t logged anywhere your IR team knows to look.
Most organizations don’t have a playbook for that kind of investigation yet. Before you expand agent access, it’s worth asking: if this agent did something unexpected tomorrow, could you reconstruct why?
“Generous Access From the Start” Is a Security Red Flag
One line in Anthropic’s post stood out to me:
“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.”
I understand the product point. Agents are more useful when they can reach more tools, documents, and context. But from a security point of view, “generous access from the start” should make us pause. That is a long way from deny all by default.
The more systems an agent can reach, the more helpful it can be. But it also becomes a bigger path for mistakes, oversharing, prompt manipulation, bad assumptions, and access nobody meant to grant. Blast radius scales with access.
What to Define Before Claude Gets the Keys
Before putting solutions like Claude Tag and agents in sensitive workflows, define the access model.
What can the agent reach? What can it do? Who can ask it to act? Which channels have which permissions? Which connectors are read-only? Which can write? Who owns the agent identity? Who reviews what it did? Who can turn it off?
These are not new questions. They are the same ones we ask about service accounts, bots, and automation. What’s new is that the answers have to account for natural language steering because the action chain now starts with whatever someone typed into a Slack thread, and whatever the agent read before it acted.
A Slack thread, document, ticket, or prompt can influence what the model says. The model output can influence what the surrounding software tries to do. Then that software may use a non-human identity to take action.
That chain needs to be visible. Start small. Use low-risk channels. Use low-sensitivity data. Keep access read-only at first. Name an owner. Review the logs. Restrict who can invoke the agent where the risk justifies it. Expand only when the organization can explain, in plain language, what the agent is allowed to do and who is allowed to ask it to do it.
That is what Anthropic’s model brings into focus.
The New IAM Question
Agent identity does not just add another account to manage. It changes the authorization question. The question is no longer only, “Does an AI agent have access?” It is now “Should this person, in this channel, be able to cause this AI agent to use that access for this action?”
And that is the new IAM problem.
