But here’s the problem nobody’s talking about: the trust layer doesn’t exist yet. Claude Tag’s “Agent Identity” model — where the AI acts under its own persona per channel, not under the requesting user’s identity — introduces a textbook confused deputy security risk. And the open-source clones are copying the same architecture without fixing it.

I’ve spent the last few weeks digging into the security model, talking to teams who are adopting it, and looking at what a proper trust layer would require. This is what I found.

What Is Agent Identity and Why Does It Matter?

Claude Tag doesn’t impersonate the user who asks it to do something. Instead, each Slack channel gets its own Claude identity with a separate memory store, tool access configuration, and permission scope. When you ask Claude Tag to run a SQL query, it does so as “Claude in #engineering-deployments,” not as “Alice from engineering.”

This is a deliberate design choice. Anthropic’s reasoning makes sense on the surface: a shared agent needs a stable identity so everyone in the channel can interact with it consistently. If Claude Tag acted as each individual user, you’d lose the shared context and persistent memory that makes a team AI coworker useful.

The channel-scoped isolation is also real. Each channel’s Claude has its own memory, its own tool bindings, and its own token spend limits. Admins can set per-organization and per-channel budgets. Audit logs track everything Claude has done and who requested each task.

On paper, it sounds reasonable. In practice, it creates a security model that would make any security engineer wince.

The Confused Deputy Problem — Claude Tag’s Security Blind Spot

The confused deputy problem is a classic computer security concept: a program with elevated privileges can be tricked by a less-privileged user into abusing those privileges. Claude Tag’s Agent Identity model is a textbook example.

Here’s the scenario. Your #engineering-deployments channel has a Claude Tag instance with access to your CI/CD pipeline, your production database read-replica, and your incident management system. Alice, a senior engineer, asks Claude to run a deployment. That’s fine — Alice is authorized. But Bob from marketing, who happens to be in the channel for a cross-team project, can also ask Claude to “run the deployment script.” Claude checks its channel-level permissions, sees it has deployment access, and executes — because the permission check is against the channel’s Agent Identity, not against Bob’s user identity.

The audit log will show “Claude in #engineering-deployments ran deployment script, requested by Bob.” But the deployment tool itself sees Claude’s API key, not Bob’s. There’s no way for downstream systems to enforce per-user access controls. Claude Tag becomes a privileged backdoor that anyone in the channel can activate.

This isn’t theoretical. The PromptQL team published a detailed teardown of Claude Tag’s Agent Identity concept and flagged this exact issue. Their assessment: “Agent Identity creates audit problems — security and audit is built around users, not Slack channels.” They built a production-grade alternative with per-user identity auth in about a day.

Why Per-User Identity Is the Harder but Correct Path

The obvious fix is to enforce user-identity authorization: when Bob asks Claude to run a deployment, Claude should check whether Bob personally has deployment permissions, not whether the channel has them. This is how every other enterprise authorization system works. You don’t give a Slack channel an API key to production — you give it to specific people.

But per-user identity is harder to implement for a few reasons:

1. Token management. If Claude acts on behalf of Bob, it needs Bob’s credentials or a delegated token. That means either OAuth token exchange on every request, or a service-to-service auth model with user assertion. Both are more complex than a single channel-level API key.

2. Context switching. A shared agent that switches identity per-request loses the simplicity of “Claude in this channel knows everything that happened here.” You’d need to either maintain a shared memory store with per-user access controls, or give each user their own memory scope — which defeats the purpose of a shared coworker.

3. Latency. Every user-identity check adds a round-trip to your identity provider. At Slack message scale, that adds up.

4. Partial delegation. Some actions should be channel-scoped (reading channel history, summarizing threads) while others should be user-scoped (writing to external systems, modifying infrastructure). Building a permission model that handles both cleanly is genuinely hard.

None of these are unsolvable. OAuth 2.0 token exchange, SCIM-based group sync, and attribute-based access control (ABAC) have been solving these problems for a decade. But they require infrastructure that Claude Tag doesn’t have and that most open-source alternatives aren’t building either.

The Open-Source Stampede — Alternatives Racing to Fill the Void

Within three weeks of Claude Tag’s launch, at least five open-source alternatives appeared: OpenTag, Ankole, Elenchus, Earshot, and slack-claude-agent. OpenTag alone hit 672 GitHub stars. The community clearly wants a self-hosted, customizable version of this pattern.

I’ve looked at the codebases of the most popular ones. The pattern is consistent: Python or TypeScript, Slack Bolt SDK, a LangChain or custom agent loop, and a single API key for tool access. Almost all of them replicate Claude Tag’s Agent Identity model — the agent acts under its own identity with channel-scoped permissions.

The Arcade.dev team published a guide showing how to recreate Claude Tag’s core pattern in about a day with Python, Slack Bolt, and their tool-access platform. Their recommendations are sensible: start with one bounded workflow (incident triage, not “AI that can do anything”), use restricted channels, dedicated identities, human approval for writes, and logging. But even their architecture uses a single agent identity per channel.

The open-source ecosystem is racing to replicate Claude Tag’s functionality, but nobody’s racing to build the trust layer. Everyone’s building the feature that looks good in a demo. Nobody’s building the one that prevents the demo from becoming a security incident.

What a Real Trust Layer Looks Like

Based on what I’ve seen working in production agent systems — and what’s missing from every Claude Tag implementation I’ve examined — a proper trust layer needs four components:

1. Identity-aware authorization. Every action the agent takes must be attributable to the requesting user, not just the agent itself. This means the agent needs to pass user identity tokens through to downstream systems, and those systems need to enforce their own access controls. OAuth 2.0 token exchange (RFC 8693) is the right pattern here — the agent gets a user-asserted token for each action, not a standing agent credential.

2. Action attestation. Every action the agent performs should produce a verifiable attestation: who requested it, what was done, what the input and output were, and whether any human approval gates were triggered. This isn’t just logging — it’s cryptographically signed evidence that can be used in compliance audits. The Microsoft Agent Governance Toolkit is the closest thing to this I’ve seen, with sub-5ms deterministic policy enforcement covering all 10 OWASP Agentic AI risks.

3. Human-in-the-loop gates for high-risk actions. Not every action needs approval. Reading channel history? Fine. Writing to a production database? That needs a human to click “approve.” The gate should be configurable per action type, per user role, and per channel. The least-privilege architecture I wrote about earlier covers this pattern in detail — scoped tools, short-lived credentials, and approval workflows are the building blocks.

4. Cross-system audit trails. The problem with Claude Tag’s current audit logs is they only cover what Claude did inside Slack. If Claude called your CI/CD system, your deployment tool, and your monitoring stack, you need to trace that action across all three systems. That requires structured correlation IDs passed through every hop, and a centralized audit store that can join events from Slack, your agent runtime, and your infrastructure. The OWASP Top 10 for Agentic Applications lists “Insufficient Audit Trail” as a distinct risk category for exactly this reason.

The Governance Gap — Audit Trails, Compliance, and Accountability

Here’s the uncomfortable question that every enterprise adopting Claude Tag needs to answer: if an AI agent makes a mistake that costs money or causes a compliance violation, who is accountable?

With Claude Tag’s current architecture, the answer is murky. The agent acted under its own identity. The channel had permission. But Bob from marketing asked it to do something Bob shouldn’t have been able to authorize. The downstream system saw a valid API call from a trusted agent. Everyone followed the rules as defined, and the result is still a problem.

This is the governance gap. It’s not a bug in Claude Tag — it’s a missing layer in the entire shared-agent paradigm. And it’s the reason I’m skeptical of the “just deploy Claude Tag and see what happens” approach I’m seeing in a lot of enterprise Slack channels right now.

Anthropic has acknowledged some of this. The audit logs, token spend limits, and channel-scoped permissions are steps in the right direction. But they’re not enough. The zero data retention policy was turned off with Fable 5, meaning chat transcripts are actively analyzed. Claude Tag runs on Opus 4.8 and is only available on Team and Enterprise plans — no free tier. The enterprise pricing implies enterprise-grade security, but the architecture doesn’t deliver it yet.

The Bottom Line — Excitement Without Trust Is a Liability

Claude Tag is genuinely impressive. The ambient behavior, async task scheduling, persistent memory per channel, and multiplayer interaction model are well-designed. 65% internal code generation at Anthropic is a real signal that this pattern works. The open-source community’s rapid response shows that the demand is real.

But the trust layer is missing. Not incomplete — missing. Agent Identity without per-user authorization is a confused deputy waiting to be exploited. Open-source clones that copy the same model are multiplying the risk, not solving it. And enterprises that rush to deploy shared AI agents without a proper trust layer are creating audit and compliance problems that will surface months later, when a regulator asks “who authorized this action?” and the answer is “the Slack channel.”

If you’re building with Claude Tag today, here’s my advice: restrict it to read-only channels first. Don’t give it write access to anything that could cause real damage. Set up your own audit logging on top of what Anthropic provides. And before you give it production access, make sure you can answer the question “who actually authorized this action?” — not just “which channel was it in?”

The technology is ready. The trust layer isn’t. And until someone builds it, every shared AI agent in Slack is a liability waiting to be discovered.

FAQ

What is the confused deputy problem in Claude Tag?

Claude Tag’s Agent Identity model gives each Slack channel a single AI identity with static permissions. Any user in the channel can ask Claude to perform actions using those channel-level permissions, even if the requesting user wouldn’t normally have access. This is a classic confused deputy: a privileged program that can be tricked by a less-privileged user into abusing its privileges. The downstream system sees a valid API call from a trusted agent and has no way to enforce per-user access controls.

What is Agent Identity in Claude Tag?

Agent Identity means Claude Tag acts under its own persona per Slack channel, not under the requesting user’s identity. Each channel gets an isolated Claude with separate memory, tool access, and permissions. This enables shared context and persistent memory — everyone in the channel interacts with the same AI coworker — but it creates audit and authorization challenges because the agent’s identity is decoupled from the human who requested each action.

What open-source alternatives to Claude Tag exist?

At least five open-source Claude Tag alternatives emerged within weeks of launch: OpenTag (672 GitHub stars in 3 weeks), Ankole, Elenchus, Earshot, and slack-claude-agent. Most replicate Claude Tag’s Agent Identity model rather than fixing its security limitations. The Arcade.dev team published a guide showing how to recreate the core pattern in about a day with Python and Slack Bolt, but even their recommended architecture uses a single agent identity per channel.

What should a proper AI agent trust layer include?

A proper trust layer needs four components: identity-aware authorization (every action attributable to the requesting user, not just the agent), action attestation (cryptographically signed evidence of every action), human-in-the-loop gates for high-risk actions (configurable per action type, user role, and channel), and cross-system audit trails with structured correlation IDs passed through every hop.

Is Claude Tag safe for enterprise use today?

Claude Tag is safe for limited, read-only use cases. Restrict it to channels where it can observe and summarize but not write to external systems. Set up your own audit logging on top of what Anthropic provides. Before giving it production access, make sure you can answer “who actually authorized this action?” — not just “which channel was it in?” The enterprise pricing implies enterprise-grade security, but the architecture doesn’t deliver it yet.