I don't understand how this is gonna fly for enterprise security and compliance. Claude needs to inherit permissions from somewhere, and those permissions will never align with the members of a slack channel. And finding the lowest common denominator of access probably results in a dumbed-down, useless experience.
The only way it works is if customers truly start treating agents as humans with the same liability as an employee.
An admin scopes permissions on a per-channel basis. It doesn't allow external actions until an owner specifically provisions that tool for that channel. I think.
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.
This sounds lovely, and ideal, but my read on this situation for, say, Google Drive, is a bit more nuanced: Anthropic's docs say that its permissions are scoped to the folders you grant access to the _user_ you create for Claude.
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...
The principle if least privilege says that one should make a request to a piece of software and grant that software the specific capabilities it needs for the purpose of that request.
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.
Which is a bad pattern. Around here, you can be granted access to most channels just with vague reasons for why you need to be in there. This is a disaster. Culture will degrade. Suspicions will grow. Security theater.
Yeah, it may indeed require some new Slack processes and discipline. But, the alternative would be account linking (like GH). Your interactions would have responses from Claude that are only visible to you if others didn't have the required permissions. It would use your credentials, etc.
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.
The only way it works is if customers truly start treating agents as humans with the same liability as an employee.