Something quietly significant has happened with Claude's release of Claude Tags. An AI assistant that used to answer within a user's session, borrowing that person's access for the length of a request, can now act as an identity of its own. It holds its own credentials, reaches its own set of tools, and operates inside your Slack workspace with a footprint that belongs to the agent rather than to whoever summoned it. For most teams, that change will arrive before anyone has decided how to manage it.

How the agent got its own identity

Claude Tag lets a team summon Claude in a Slack channel by tagging it, and to do anything useful, Claude needs to access the tools your team already uses. Anthropic handles this by giving Claude its own service account credentials, grouped into what it calls Access bundles and scoped to particular channels, with spend metered against your organization. Strip away the packaging, and the mechanism is familiar. A new non-human identity has been provisioned inside your environment, and it has standing access to real systems.

The detail that matters is the shift from borrowed access to owned access. Until now, an AI feature operated under the permissions of the human using it, meaning its activity was indistinguishable from that person's. Claude Tag separates the two. The agent carries its own identity, which is exactly what good practice has been asking for, because you cannot govern what you cannot tell apart from a legitimate user.

Why borrowed access hid the problem

When an agent borrows a user's access, the risk does not vanish. It moves within a human identity, blending with everything that person is genuinely entitled to do, making anomalous agent behavior almost impossible to isolate. The moment the agent acts as itself, that same risk steps into the open, where you can name it, scope it, and revoke it. Visibility of that kind is a real gift to a security team.

The catch is what teams do with the gift. A visible identity that nobody owns, scopes, or monitors is still a liability. It has only moved from hidden to plainly unmanaged, which is progress on paper and very little comfort in practice. The questions that follow are the ones every team should be ready to answer about each agent Claude Tag creates:

• Which agents now exist across your channels and connected tools
• Who owns each one, the way a service account has an owner
• What systems, data, and APIs can each one reach
• Which credentials, OAuth grants, and service accounts does it depend on
• Whether its access is least privilege and time-bound, or standing and quietly growing
• Whether you would notice the day its behavior drifts

The access decision has already been made

Here is the part that tends to get lost. Every agent has to reach something to be useful, and the instant it reaches anything, a privilege decision has already been made on your behalf. With Claude Tag, that decision happens when someone builds the Access bundle, and under time pressure, the easy choice is a broad one. A generous bundle is convenient on the first day and a standing liability by the third month, because the access outlives the task it was created for.

This is not a hypothetical concern. By 2029, analysts expect half of all successful AI agent attacks to weaponize the agent's own access rather than any flaw in the underlying model. An over-permissioned agent is a better target than a buggy one, and the permissions are settled long before any attacker shows up. The exposure exists the moment the bundle is provisioned, which is why this has to be solved at the identity layer rather than at the model.

The protocol layer nobody is governing

Underneath the agent identity sits a layer that almost nobody is watching. When Claude reaches into your tools, it connects through integration protocols, increasingly the Model Context Protocol, which is how agents query databases, call APIs, and pull context at runtime. Each of those connections is a privileged decision made implicitly, usually without review and with no record of what passed through it afterward. Consider how quickly that compounds across every channel and every connected tool in a single workspace.

The uncomfortable truth is that you can run flawless identity practices for your people and still leave the agent's path wide open. Closing it means securing how agents authenticate and what they are authorized to do at the protocol layer itself. The MCP Auth Gateway is built for exactly that, and it operates within the same identity layer that already covers your other identities, so the agent's access is controlled within the fabric you already run.

Slack was already full of identities you could not see

It helps to remember that Claude Tag is landing on a surface that was already crowded. A typical Slack workspace includes people, guest accounts, bots, and OAuth tokens, and most teams are quietly surprised by what a close look reveals: forgotten admins, idle bots that still hold privileged scopes, and tokens issued for an integration that was retired a year ago. Claude Tag adds autonomous agents on top of a population that was already difficult to see in full.

That is the real reason this is hard. The agent is not arriving in a clean, well-mapped environment. It arrives in a context where existing identities are only partially understood, and it inherits all the blind spots that existed before.

We built for this before the agents arrived

Unosecur shipped its Slack Connector well before Claude Tag existed, and the design choice behind it is the reason it handles this new wave without changing anything. The Connector treats every Slack identity as something to inventory and account for, people, guest accounts, bots, and OAuth tokens alike. An agent created by Claude Tag presents as exactly that, a bot or app identity carrying its own tokens, grants, and service-account credentials. It lands within existing coverage the same day it appears, with no new product bolted on to chase it.

The connector feeds all of those identities into the Unified Identity Fabric, where each one sits alongside every identity across your environment, AI agents, non-human identities, and human identities, measured against the same posture checks and the same runtime behavior analysis. It deploys agentless and read-only over OAuth and goes live in minutes, so the first useful answers arrive the same day you connect it.

Here is what it does once a Slack identity is in the Fabric:

• Builds a full identity inventory and posture, with flags for dormancy, missing MFA, SSO bypass, and privilege drift
• Surfaces Shadow Admins by tracing nested roles back to the effective admins nobody assigned on purpose
• Learns a behavioral baseline for every identity, so a change in what an agent does reads as a signal instead of noise
• Runs continuous runtime checks that fire on privilege escalation or on dormant privileged accounts
• Remediates in one click, disabling, revoking, or downgrading access from inside the platform, with a logged and exportable audit trail

Because Unosecur treats AI agents as first-class identities, the same discovery, classification, and behavioral baselining extend to the agents Claude Tag creates, handling them as one more kind of identity to govern rather than a special case bolted on later. Unosecur’s MCP Auth Gateway can secure how those agents authenticate and what they are authorized to do at the protocol layer, inside the same fabric.

Why it all comes back to identity

Every wave of technology has introduced a new way to operate within your systems. Cloud added workload roles, SaaS added tokens and integrations, and the agentic shift adds autonomous identities like the one Claude Tag just created inside your Slack. The interfaces keep changing their shape, and the question underneath them has not moved in twenty years: who or what holds access, what it can do once inside, and whether anyone is watching. Claude Tag is being read in plenty of places as a convenient new Slack feature. It is more useful to read it as a preview of how every capable tool will arrive from here on, maintaining its own identity and access, needing an owner, a boundary, and a record from the first minute it runs. Whatever your teams adopt next, you keep control of it the same way you always have: by controlling the identities.