Inside Claude Tag: How @Claude Actually Works, and Why Identity Is the Hard Part

Anthropic just shipped a version of Claude that lives in your Slack and works like a coworker. The interesting story isn’t the chat box. It’s how the agent gets an identity, how it touches your tools, and what could go wrong. Here’s the whole thing in plain language.

~12 min read | For builders, PMs & security-minded readers | No deep expertise required

01 · A new teammate, not a new chatbot

On June 23, 2026, Anthropic introduced Claude Tag: a way to bring Claude into the places your team already works, starting with Slack. You grant Claude access to selected channels, connect it to the tools, data, and codebases you choose, and then anyone in the channel can type @Claude and hand off a task. Claude breaks the request into steps, works through them with the tools it has, and replies in a thread when it’s done.

Anthropic is blunt about how central this has become internally: they say 65% of their product team’s code is now created by their in-house version of Claude Tag, and that tagging @Claude is one of the main ways work gets done. Not just for engineering, but for chasing product metrics, working support tickets, and root-causing bugs.

So how is this different from Cursor’s background agent from a year ago?

It’s a fair question. In June 2025, Cursor shipped “Background Agents in Slack”. You mention @Cursor in a thread, it reads the conversation, runs remotely in a secure environment, and opens a pull request in GitHub. On the surface that sounds identical: tag a bot in Slack, get work back. But the two solve different problems.

The short version: Cursor put a coding agent where your team chats. Claude Tag is trying to put a colleague there, one with memory, initiative, and its own to-do list. And the moment you have a colleague that acts on its own across many tools, you hit a problem Cursor’s model mostly sidesteps: who is this agent, and whose permissions does it use?

02 · Agent identity: Claude gets hired as an employee

Today, when you connect Claude (or most AI assistants) to a tool through a connector, the assistant acts as you. You log into Google Drive, you grant access, and the model reads and writes using your permissions and your name. That works fine for one person chatting with one assistant. It falls apart the moment Claude sits in a shared channel. As Anthropic explains in their agent identity write-up, “act as the user” breaks for two reasons:

• It's multiplayer. If three engineers and a PM are all in a channel, whose permissions should Claude use? There's no single right answer.
• ‍It's autonomous. The agent schedules its own work and acts hours after the person who asked has logged off. Borrowing a human's live session doesn't fit a worker that runs on its own.

Anthropic’s answer is agent identity: instead of borrowing a human’s credentials, Claude gets its own accounts, provisioned by an admin and tied to the workspace. It posts in Slack as the Claude app, opens pull requests as the Claude GitHub App, and queries your data warehouse under its own service account. Claude acts as itself, like a new employee with their own logins, not as any specific human.

How this differs from how connectors work today

With a normal connector, permissions follow the person. With agent identity, permissions follow the channel. An admin defines a baseline identity at the workspace level, and each channel inherits it, then overrides where it makes sense. Crucially, a person who doesn’t personally have repo access can still ask Claude to read that repo, if the channel’s profile grants Claude that permission. That’s a real departure from traditional per-user access control lists, and it’s deliberate.

Identities are also walled off from each other. Claude Tag creates a distinct identity for each private channel; public channels share a workspace-level identity. What Claude learns in a private legal channel never leaks into engineering. Revoking the identity cuts Claude’s access everywhere that identity was used. One switch, not an audit of dozens of accounts.

The part that surprises people: the model never sees the token

When Claude needs to call a tool, it doesn’t hold the secret credential in its “head.” When an admin adds a connection to a channel, the credential is stored separately, mapped to that channel’s identity, and injected at the network boundary at request time. In practice Claude writes a request with a placeholder where the token goes, and the real token gets attached outside the language model, as the request leaves the sandbox.

03 · Talking to tools over APIs, not MCP

MCP (the Model Context Protocol) is a standard way to expose tools to a model. It’s great, but it adds a layer: someone has to build, host, and maintain an MCP server for each tool, and the model is limited to whatever actions that server exposes. Claude Tag leans on a simpler idea: let Claude call the tool’s own API directly, usually with plain HTTP requests it composes itself. Claude already “knows” how thousands of public APIs work and can read API docs on the fly, then the token is injected at the edge.

Why “scary” and “powerful” are the same sentence here

Direct API access is enormously flexible, but flexibility cuts both ways. The same token that lets Claude read issues can often delete them, if the token’s scope allows it. So the real control surface isn’t the prompt. It’s the token’s permissions. Give Claude a read-only key and no amount of clever prompting (or prompt injection) lets it write. The boundary lives in infrastructure, not in the model’s good behavior.

The mental model: Don’t think “what should I tell Claude not to do?” Think “what is this token physically allowed to do?” The token is the fence. The prompt is just instructions inside the fence.

04 · Where it can go wrong, and how to start safely

An autonomous teammate with API access and its own logins is genuinely useful. It’s also a new class of risk. The failure modes worth naming before you turn it on:

• Destructive endpoints. A token scoped for convenience may also expose DELETE and other write actions. An agent that “helpfully” cleans up could remove records you wanted. Scope tokens to read-only wherever the job allows it.
• ‍Access leakage across people. Because access follows the channel, not the person, someone without direct access to a system can ask Claude to act on it. A channel’s membership effectively defines who can reach that data.‍
• Tokens or secrets ending up back in the conversation. If a response, error message, or log echoes a credential back into the session and it isn’t scrubbed, the secret can persist in the transcript and memory.‍
• Over-broad data exposure. Connect a data source to a public or shared channel and you’ve effectively shared it with everyone who can tag Claude there, and with Claude’s memory.

A starter checklist

Anthropic’s own advice is to start with a small baseline, read the audit trail, and widen access one deliberate grant at a time. Concretely:

• Use specific Slack channels. Start with a few, ideally private ones with known membership, and expand from there.
• Connect only data that's safe for the whole channel. Treat anything you wire up as visible to every person who can tag Claude there.
• Use scoped access. Issue read-only tokens by default; grant write or delete only where the work truly needs it.
• Add safety instructions. Pair the technical limits with explicit standing instructions — belt and suspenders, with the token as the real belt.
• Watch the audit log. Review what Claude did before you widen scope.

05 · Willow: agent identity you can control.

Everything above points to the same conclusion: the agent is only as safe as the identity and the boundary around it. That’s exactly the layer the Willow API Proxy is built for. Instead of hoping each tool’s token is scoped correctly and trusting that secrets never leak into the model, Willow sits between your agents and your tools as the control plane for agent identity.

• Create an identity for each agent. Every agent gets its own provisioned identity – a real "employee," not a borrowed human account – so its actions are attributable and revocable.
• Apply the same policies you already use for MCPs and CLIs. Reuse your existing access rules instead of inventing a parallel permission system for agents.
• Capability-by-API point. Define exactly which API operations are allowed, not just token scope, with risk-rated API sets for 80+ common connectors
• Guardrails on every call. Each request is inspected in real time for the risks that actually matter with autonomous agents: prompt injection (so a poisoned page or message can't hijack the agent), secrets and tokens (so credentials never leak into prompts, responses, or memory), and PII (so sensitive personal data is caught before it goes somewhere it shouldn't).
• Full audit logs. Because the agent has its own identity, every call is recorded under that machine identity – so you can reconstruct exactly what the agent did, when, and against which system.
• A simple kill switch. When something looks wrong, cut the agent's access instantly – one switch, everywhere.

Why this fits the agent-identity era: Claude Tag moves the security question from “what can this user do?” to “what can this agent do in this compartment?” The Willow API Proxy is where you answer that question, and enforce it on every single call, with the token never exposed to the model.

The takeaway: Claude Tag makes a genuinely new kind of teammate possible. Autonomous, multiplayer, with its own identity. The companies that get the most from it will be the ones who treat that identity as something to govern, not just enable.

Sources: Introducing Claude Tag (Anthropic, Jun 23 2026); Agent identity: a new access model (Claude, Jun 24 2026); Background Agents in Slack (Cursor, Jun 12 2025).