The only way it works is if customers truly start treating agents as humans with the same liability as an employee.
What's cooler is then it can view/add/remove people from channels, so it can conduct access reviews -- overall I consider it a security improvement.
But people can be invited to a channel after @Claude is provisioned. So yeah, I suppose you'll need to be deliberate about channel memberships.
That would defeat the stated purpose of collaboration/shared context, it would essentially just be another surface for your private Claude sessions.
Just gotta either decide not to use it or use it and not be willy nilly about the Slack channels in which it's provisioned.
Having the a program that (a) follows directions from any user, (b) quite possibly follows directions from any other input it might encounter and (c) has the same broad capabilities available for every request is, well, not least privilege.
This creates an unfortunate situation where, for example, I can't scope a given channel's Claude Tag to _only_, say, a project's shared drive or specific folders, because I'm using a custom claude@ Google account in my org, and its permissions have to be all-encompassing.
It also means I can't escalate privilege and expose certain documents that I would like to: say I have a private #hr channel that I would like to have access to our HR shared drive docs with proprietary information. My understanding is that any user in any channel with @claude tag in it would be able to interrogate Claude about any file that the Claude Google user has access to, regardless of which channel they're in.
I'm trying to determine if the way around this is the alternate Google service account option, but that mentions domain-wide delegation in such a manner that it makes me think it would replicate the problem, and I obviously don't want to create custom Google accounts for each project scope in my org...