Notifications
Clear all
Topic starter
01/07/2026 2:02 am
TL;DR: Channel-level agent permissions are now a governance problem, not just a product design choice, according to Hush Security. A Slack-native agent with its own channel-scoped identity can create confused-deputy access, long-lived NHI sprawl, and attribution gaps when access is granted at the channel level instead of the action level.
NHIMG editorial — based on content published by Hush Security: Table of Contents Claude Tag and its Slack-native agent authorisation model
Questions worth separating out
A: Security teams should make the agent’s effective permissions the intersection of the requester’s entitlements and the agent’s own scope.
Q: Why do channel-scoped AI agent identities create NHI governance risk?
A: Channel-scoped agents create NHI governance risk because each identity can become a long-lived credential with its own lifecycle, ownership, and revocation burden.
Q: What do security teams get wrong about audit logging for AI agents?
A: Teams often assume that logging the agent identity is enough, but shared-agent logs rarely preserve the human request, business purpose, or exact action path.
Practitioner guidance
- Bind agent permissions to requester entitlements Require the agent’s effective access to equal the intersection of channel scope and the initiating user’s own permissions.
- Inventory each channel agent as a governed NHI Track ownership, expiry, scope, and offboarding for every agent identity created per channel.
- Move sensitive operations to action-level approval Reserve high-risk actions for task-scoped grants and explicit approval, rather than broad channel-level access.
What's in the full article
Hush Security's full analysis covers the operational detail this post intentionally leaves for the source:
- The channel-by-channel authorisation model and how it differs from inherited user permissions in practice
- The specific confused-deputy and auditability risks raised by ambient multi-channel agent use
- The proposed identity-aware access direction, including how the agent ∩ user model is meant to work
- The article's own roadmap discussion around just-in-time grants and cross-domain identity broker patterns
👉 Read Hush Security's analysis of Slack-native AI agent identity and access scope →
Slack-native AI agent identity: what it means for IAM teams?
Explore further
01/07/2026 2:21 am
Least privilege was designed for identities whose permissions can be checked against a known user at request time. That assumption fails when a Slack-native agent can be invoked by any channel member while retaining its own broader channel scope. The result is not just over-permissioning, but a broken delegation model where the requester’s entitlements no longer bound the resulting action. Practitioners should treat this as a governance failure in delegated authorisation, not a minor policy gap.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- 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.
A question worth separating out:
Q: When should organisations use action-level approval instead of broad channel access for AI agents?
A: Organisations should use action-level approval whenever the agent can read sensitive data, trigger external workflows, or change privileged state. Broad channel access is too coarse for those tasks because it authorises the whole persona, not the specific act. Narrow grants reduce blast radius and make review decisions clearer.
👉 Read our full editorial: Slack-native AI agent identity exposes channel-level privilege drift
