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 a day 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 a day 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_ a day 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 a day 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_ a day 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 a day 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.

	▲	_pdp_ 14 hours ago \| parent [-]
		Part of the threat model. If that is an issue then don't add the capability to the agent. It is simple as that. But we cannot guarantee that the agent wont leak some information. So if you connect personal accounts (i.e. oauth) this information can be guarded with technical controls that sit outside of the agent. If the agent is authenticated with shared credentials then you have to add instructions and other soft guardrails but ultimately you should assume that everyone has access to the information.