| ▲ | muglug 4 hours ago |
| [I work for Slack, opinions very much my own] Having agents see everything you and your colleagues see is cool. The challenge comes when you want to make certain things private to certain people. In that world you don’t want multiplayer agents leaking data, so you end up having to write and maintain complex rulesets about what specific resources agents have access to. Single-player agents, on the other hand, are much more straightforward — they act on a single user’s behalf, and then the challenge is ensuring the single-player agent cannot exfiltrate private data into a shared space unless the user specifically permits it. |
|
| ▲ | swader999 2 hours ago | parent | next [-] |
| Private groups are the worst thing in a truly collaborative environment. Would be nice in Slack to have a Publish this whole freaking thread to a public channel button. |
| |
| ▲ | tomaskafka 2 hours ago | parent | next [-] | | But who is allowed to press it? If anyone, then anyone can expose career ruining messages from someone else, even inadvertently. | | |
| ▲ | coffeebeqn 2 hours ago | parent | next [-] | | Can’t anyone already do that with a screenshot or a log dump? I’m always assuming company provided comms platforms are fully readable by the admins | | |
| ▲ | ivan888 43 minutes ago | parent | next [-] | | That's a good operating assumption, and I usually think this way too. It turns out Slack actually requires legal process or consent of parties to provide private messages to admins: https://slack.com/help/articles/204897248-Guide-to-Slack-imp... But of course yes, another party could simply take a screenshot | | |
| ▲ | fcarraldo 34 minutes ago | parent [-] | | They certainly can on Business and Enterprise plans. There’s some lip service to following employee policy and applicable laws, but if the policy allows (most do), and you’re in the US, the admins can do it. |
| |
| ▲ | 35 minutes ago | parent | prev [-] | | [deleted] |
| |
| ▲ | nine_k 17 minutes ago | parent | prev | next [-] | | Every thread participant should check [_] I agree before the thread is published. An inappropriate message may not be about something unsavory but about something private. Information about a contract which is not yet public. A discussion of a candidate who is then hired, and reads it. Etc. | |
| ▲ | jackbravo 2 hours ago | parent | prev | next [-] | | If you wrote it on your company's slack space, it is not really private to the company. Everytime I have a "private" conversation in Slack I have the understanding that the information could be shared. Even now there is a share button not for the whole conversation but yes for individual messages | | |
| ▲ | tomjakubowski an hour ago | parent [-] | | It's potentially open to the public as well, given the right legal action. The Enron email dump revealed secrets that presumably ended several marriages. |
| |
| ▲ | SoftTalker 31 minutes ago | parent | prev | next [-] | | Who would put a career ruining message on slack or any other company platform/service? | | |
| ▲ | garciasn 13 minutes ago | parent [-] | | Seemingly benign and/or entirely work-related messages can turn out to be career-ending when weaponized by the company. | | |
| |
| ▲ | swader999 2 hours ago | parent | prev | next [-] | | 1. A workspace admin or 2. by permission of all on thread, or AI inspects contents and gates on 1 or 2 if anything sensitive. This isn't 1990, we can program stuff now. | | |
| ▲ | hnlmorg an hour ago | parent | next [-] | | The OPs comments weren’t just a hypothetical. We’ve already seen numerous instances where agents have leaked private data. Even GitHub’s own Copilot has been found guilty of these vulnerabilities. | | |
| ▲ | myrandomcomment an hour ago | parent [-] | | I agree. We have a leadership channel at work for well, the leadership team. Those conversations are sensitive. Evaluations, hiring bands, salaries, future product planning, markets, funding, etc. Access to that channel is strictly controlled. I am not worried about anyone taking a screenshot. In the case of allowing an AI agent to participate in the channel, I would be worried about that AI using information from that channel to answer a question outside of that channel. Keeping the agents "learnings" clearly behind a "firewall" would be of great importance. Beyond that, the team are free to have private conversations between themselves. This is NOT something we log. At the end of the day, hiring good people and trusting them is important. The logic of making sure the AI does not leak those conversations also applies. It is a new world, re:AI. It has its uses and things are changing at a rapid pace. It is not clear to be the protections we have implemented in todays paradigms are well implemented yet in the new AI world. |
| |
| ▲ | Exoristos an hour ago | parent | prev [-] | | > This isn't 1990, we can program stuff now. What a curious thing to say. My impression has been, if you put the accomplishments of computer science prior to 1990 against those subsequent, the prior would be more impressive, perhaps by a lot. |
| |
| ▲ | Zambyte 2 hours ago | parent | prev | next [-] | | The only actually interesting thing about this regarding "career ruining messages" is how easy accidental disclosure violations would become. | |
| ▲ | tayo42 an hour ago | parent | prev [-] | | That can already happen with screenshots |
| |
| ▲ | aftergibson 29 minutes ago | parent | prev [-] | | I'm confused are against the idea of private groups at all or just that you can't change the visibility settings later on? |
|
|
| ▲ | another-dave 2 hours ago | parent | prev | next [-] |
| My understanding of what they were saying Buzz is is that agents are "1st class" users in their own right, rather than being an app integration. If you have a user called Claude, then you just apply ACL as normal & you don't care if they're human or bot, right? |
| |
| ▲ | jaggederest 2 hours ago | parent [-] | | The issue is when users interact with claude, what can they see? If the AI can see super-secret-payroll-details.md - is it allowed to discuss that with any user? is there some sort of internal ACL within claude that asks pretty please don't tell everyone they're underpaid? That's why multiuser agents can be an issue. The other way to do this, is to have claude installed for everyone, and any user's chat with claude uses their personal permissions via something like oauth delegation or AWS IAM role kinda things. But that, again, is complicated ACL logic living through the delegation of roles and access | | |
| ▲ | AlotOfReading 5 minutes ago | parent [-] | | I'm not sure the permissions problem is solved even if we assume models inherit user permissions. Imagine I'm a manager and someone contacts me about an HR incident involving one of my reports, or other sensitive information. The agent probably shouldn't have access unless I explicitly provide it. |
|
|
|
| ▲ | _pdp_ 3 hours ago | parent | prev | next [-] |
| I agree with what you are saying but this is not how we solved the issue with who can access what. In our cloud harness we have the notion of shared and private secrets. When something is authenticated with a shared secret it is basically something that can be used in a public setting. If something is private then it can be only accessed via trusted channel. It works for slack, telegram, etc. In fact, our slack agents are very strong this department and it is guaranteed there is zero leak of private information. |
| |
| ▲ | datadrivenangel 3 hours ago | parent [-] | | And if someone gets access to a channel that they shouldn't? The best norms around slack channels is to have most channels be public, but have norms where not everyone is in every channel. | | |
| ▲ | hibikir 3 hours ago | parent | next [-] | | I have lived in organizations where under 1% of messages were made on public channels. The experience of finding information in slack, or even knowing if there's a private channel where all of this is discussed, but where nobody invited you to, is not one I wish on anyone. | |
| ▲ | _pdp_ 3 hours ago | parent | prev [-] | | No channel will disclose private information. The only way to get that to work is to DM the agent directly or to use slash commands which are ephemeral / private. | | |
| ▲ | datadrivenangel 2 hours ago | parent [-] | | so your agents can't access any private information in public channels? Not very useful. Still probably better than Claude's new bot which requires a service account per channel! | | |
| ▲ | _pdp_ 2 hours ago | parent [-] | | Hang on a second. You think accessing private information in a public channel is a good idea? If a tool is authenticated as personal then it can be only accessed under personal context - i.e. privately. Now if the author of the agent wants to add tools authenticated with shared secrets that is something should be considered in the threat model. In other words: - reading my personal emails in a public setting - not ok
- reading the agents shared inbox in a public setting - probably ok depending on the threat model | | |
| ▲ | pests 18 minutes ago | parent [-] | | > not ok - reading the agents shared inbox in a public setting - probably ok depending on the threat model This is never secure. Some SAAS apps have automatic enrollment into company/teams based on email domain. So you can sign up with the email address of the agent and then ask for any 2fa code or other emails. |
|
|
|
|
|
|
| ▲ | GodelNumbering 4 hours ago | parent | prev | next [-] |
| > so you end up having to write and maintain complex rulesets about what specific resources agents have access to. Why wouldn't you simply use the group chat ID (+more) to key the conversations on? |
| |
| ▲ | paxys 3 hours ago | parent [-] | | Because there’s an unlimited number of groups with different combinations of memberships. If I am in group A but not group B and an agent is in both, what is it allowed to share with me? | | |
| ▲ | ahf8Aithaex7Nai 2 hours ago | parent [-] | | I'd like to see this problem solved in such a way that your group memberships are transitively applied to your access to agents. In other words: you shouldn’t be allowed to talk to an agent at all if, at a given point in time, that agent is or was in a group that you are not or were not in at that time. Does that make sense? I don’t know how practical this restriction is, but letting the AI manage such permissions on its own seems reckless to me. | | |
| ▲ | paxys 2 hours ago | parent [-] | | These kinds of rules never survive real world tests. For example if I create a private group just for myself and auto invite every agent in the company into it, does that mean no one can now use any of them? |
|
|
|
|
| ▲ | dgunay 2 hours ago | parent | prev | next [-] |
| Maybe this is naive or startup-brained of me: I understand not wanting HR-related things to be potentially exposed by a misaligned agent, but when it comes purely to the building of software I personally do not care at all who can read the code/discussions & engage with the process. |
| |
| ▲ | muglug 2 hours ago | parent [-] | | Totally get that for code! But there are orgs where non-code things are compartmentalised — maybe for leak reasons — that still want to employees to make use of agents. |
|
|
| ▲ | zackham 3 hours ago | parent | prev | next [-] |
| all ingested data and all derivations of that data can link to source channel and associated ACL that syncs with the source. then search/reads/etc just join on and respect the ACL. not that complicated to manage for things like slack, meetings, etc. |
|
| ▲ | 4 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | 3 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | TZubiri 3 hours ago | parent | prev | next [-] |
| The product seems to use the same 'scoping' mechanism that humans would use, so you can give agents access to whatever 'channels' you want. The issue seems to be that they 'invented' an auth and permission protocol instead of delegating to something existing, it would be as if they thought their idea of permissions were novel. |
|
| ▲ | mrcwinn 3 hours ago | parent | prev | next [-] |
| Seems easy for Buzz to solve. I’m just happy to have an alternative to Slack. |
|
| ▲ | 4 hours ago | parent | prev [-] |
| [deleted] |