Claude Tag gives AI agents their own identity in Slack

At a glance

What this is: Claude Tag shifts AI agents in Slack from borrowed user permissions to owned non-human identities with their own credentials and tool access.

Why it matters: That matters because IAM, NHI, and human identity teams now have to govern agent ownership, scope, and revocation as a distinct identity class, not as hidden user activity.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Unosecur's analysis of Claude Tag and AI agent identity in Slack

Context

Claude Tag gives an AI agent its own identity inside Slack, backed by service-account credentials and scoped access bundles. That moves the agent from borrowed user access into a governable non-human identity, which is exactly where IAM and NHI programmes need clearer ownership, scope, and revocation discipline.

The security issue is not that the agent can act, but that it now acts as a distinct identity in an environment already full of bots, OAuth tokens, and overlooked privileges. Once agent identity is visible, the governance question shifts from detection to lifecycle control: who owns it, what it can reach, and when its access should be removed.

Key questions

Q: What breaks when an AI agent gets its own identity instead of borrowed user access?

A: Borrowed access hides agent behaviour inside a human account, which makes attribution, review, and revocation unreliable. Once the agent has its own identity, the programme must manage it as a distinct non-human identity with owner, scope, lifecycle, and protocol boundaries. Without that shift, governance remains blind to the real actor.

Q: Why do AI agents complicate NHI governance in Slack and similar tools?

A: Because they turn collaboration platforms into identity-bearing execution surfaces. The agent may look like a chat feature, but it actually holds credentials, uses connected tools, and accumulates standing access. That means NHI governance has to cover ownership, entitlement scope, and offboarding inside the collaboration layer, not only in central IAM.

Q: How do teams know if an AI agent's access is too broad?

A: If the agent can reach systems or data unrelated to the task it was created for, the access is too broad. Warning signs include bundles that span multiple channels, reused credentials across tools, and no named owner for review. Effective control means the access can be explained, limited, and removed without breaking unrelated workflows.

Q: Who should be accountable when an AI agent causes an access incident?

A: The accountable party should be the business owner of the agent, supported by IAM or platform teams that provisioned the identity and controls. If no owner exists, accountability has already failed. Any governance model for AI agents needs a named owner, an approval path, and a revocation process before the agent is allowed to operate.

Technical breakdown

Why borrowed user access hides AI agent risk

When an AI assistant operates inside a human session, its activity blends into the user's legitimate permissions and audit trail. That creates attribution ambiguity, which makes anomalous behaviour hard to separate from normal work. Giving the agent its own identity improves traceability, but it also creates a new managed identity object with credentials, scope, and lifecycle requirements. In identity terms, the problem stops being invisible misuse and becomes explicit NHI governance. Practical controls now need to follow the agent as an identity, not as an event inside a user's session.

Practical implication: inventory agent identities separately from human users and tie each one to a named owner.

Access bundles, standing privilege, and tool-layer authorisation

Claude-style agent access depends on prebuilt bundles that define what tools, APIs, and data the agent can reach. That is an ordinary identity design pattern, but it becomes risky when the bundle is broad enough to survive beyond the task it was created for. Standing privilege is the core weakness: once the bundle exists, the agent can repeatedly reuse the same access without fresh intent or review. The control problem is therefore not model safety, but durable authorisation at the identity and protocol layers.

Practical implication: scope bundles tightly, then review them as living entitlements rather than one-time setup choices.

Why protocol gateways matter for agent identity governance

Agent identity does not stop at the Slack workspace. It extends through the protocol used to connect the agent to databases, SaaS tools, and APIs, which is where hidden authorisation decisions often accumulate. A protocol gateway lets teams inspect and constrain that traffic instead of treating it as a black box behind the chat interface. This is the difference between governing a visible identity path and inheriting unreviewed downstream access. Without protocol-layer governance, the agent may be managed at the surface while remaining unconstrained underneath.

Practical implication: place authorization controls at the protocol layer, not only in the front-end app or workspace.

Threat narrative

Attacker objective: The objective is to use the agent's legitimate identity and standing access to expand control, exfiltrate data, or trigger actions without needing separate compromise.

1. Entry occurs when an AI agent is granted its own Slack identity and connected tool access through an access bundle.
2. Escalation happens when that bundle becomes standing privilege across channels, APIs, and service accounts, allowing repeated action without fresh review.
3. Impact follows when unmanaged agent access expands the blast radius of data access, tool execution, and credential dependency across the workspace.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Claude Tag turns AI assistants into governable identities, and that is the right architectural shift. Borrowed user access makes agent behaviour hard to attribute and harder to revoke. A distinct identity creates the possibility of ownership, scoping, and lifecycle control. The practitioner implication is clear: treat the agent as an NHI from the moment it is provisioned, not as a convenience feature attached to a human account.

Standing access is the real governance problem, not the chat interface. Access bundles that outlive the original task become durable authorisation objects, and that is where NHI governance breaks down. The issue is not whether the agent can connect to tools, but whether its privileges can persist long after the business need has changed. Practitioners should read this as a lifecycle failure mode, not a product feature.

Identity does not remain borrowable once an agent has its own runtime authority. The assumption that AI activity can be governed through the human user's entitlements was designed for session-bound assistance. That assumption fails when the actor is autonomous in identity terms because the agent owns its credentials, selects its actions at runtime, and operates outside the user's direct session. The implication is that access review models built for human-paced use cannot fully explain or constrain agent behaviour.

Ephemeral-looking automation can still create permanent identity debt. A Slack agent may appear transient to the business user, yet its credentials, tool grants, and audit obligations can remain durable. That gap between perceived ephemerality and actual persistence is where organisations accumulate unmanaged machine access. The practitioner implication is to govern agent identity as long-lived infrastructure, even when the user experience feels temporary.

Platform consolidation will increasingly move agent identity into existing collaboration surfaces. Slack is only one example of a broader pattern where AI capabilities arrive inside tools already trusted by the business. That increases the chance that NHI controls are bypassed by design assumptions rather than explicit exception. The practical response is to extend NHI governance into collaboration platforms before the next agent lands there.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Ultimate Guide to NHIs also shows that 97% of NHIs carry excessive privileges, which is the control pattern AI agents inherit when bundles are left broad.

What this signals

Agent identity is becoming the new governance boundary. As more collaboration platforms embed AI execution, teams should expect the number of governed non-human identities to rise faster than the number of human users. With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, the default failure mode is over-granting before ownership is even assigned.

Lifecycle discipline will separate visible control from actual control. If an agent can be created quickly but not reviewed, rotated, or revoked with equal discipline, the programme only appears mature. That is why access governance inside Slack-like environments should be tied to the same offboarding, review, and entitlement controls used for other machine identities.

Identity sprawl in collaboration tools is now a front-line NHI problem. Teams that already struggle with dormant bots, legacy OAuth grants, and forgotten admin roles should expect AI agents to compound the same exposure patterns. The next step is not a new category of monitoring, but a broader identity fabric that treats chat agents, service accounts, and human users as one governed surface.

For practitioners

• Create a separate inventory for AI agent identities Record every agent as a distinct identity object with owner, purpose, channel scope, connected tools, and revocation path. Do not let agent activity remain buried inside the human user record.
• Tighten access bundles before deployment Review each bundle for excessive scopes, long-lived grants, and unnecessary tool connections. If the bundle cannot be explained in a single task context, it is already too broad.
• Move authorisation checks to the protocol layer Use a gateway or equivalent control so that agent-to-tool traffic is inspected and constrained where the access is actually exercised, not just where the user interface starts.
• Add agent offboarding to lifecycle processes Define what it means to disable, rotate, or revoke an AI agent the same way you would for a service account, including an owner, a trigger, and a verification step.
• Monitor for behaviour drift and scope creep Baseline expected agent actions, then alert when the identity begins reaching new tools, expanding channel use, or acting outside its original purpose.

Key takeaways

• Claude Tag shifts AI assistants from borrowed user permissions to owned non-human identities, which makes governance possible but also introduces a new managed access object.
• The main risk is standing privilege, not the chat surface itself, because access bundles can outlive the task and quietly expand the agent's blast radius.
• IAM teams should inventory, scope, offboard, and monitor AI agents as first-class identities before collaboration platforms become the default home for unmanaged machine access.

Key terms

• Agent Identity: An agent identity is a machine-held identity assigned to an AI assistant or autonomous workflow so it can authenticate, access tools, and act independently of the human who invoked it. In governance terms, it behaves like an NHI and must be owned, scoped, reviewed, and revoked like any other non-human credential set.
• Access Bundle: An access bundle is the packaged set of permissions, tool links, and credential dependencies given to an agent so it can complete work. It is useful for provisioning, but risky when the bundle becomes broad or permanent. For agentic systems, the bundle is effectively an entitlement profile that must be lifecycle-managed.
• Standing Privilege: Standing privilege is access that remains available after the immediate need for it has passed. For AI agents, this means credentials or tool grants can persist across sessions, creating a wider blast radius than the task requires. It is one of the most common reasons machine identities become difficult to control.
• Protocol-Layer Authorisation: Protocol-layer authorisation is the control point where an identity is checked at the point it connects to tools, APIs, or data services. It matters because front-end approval alone does not constrain what the identity can do once it reaches downstream systems. In agentic environments, this layer is where hidden privilege becomes visible.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• The Slack Connector inventory model for people, guest accounts, bots, and OAuth tokens
• How the Unified Identity Fabric classifies AI agents alongside other identities
• The MCP Auth Gateway approach for constraining agent authentication and tool access
• The one-click remediation flow for disabling, revoking, or downgrading access

👉 The full Unosecur post covers Slack identity discovery, protocol-layer controls, and agent remediations.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.