Platform

Security

Who can read what — encryption, isolation, confirmations and retention.

Bloosh is only useful if you give it the real material: inbox, calendar, contracts, the things you would not put in a shared doc. That only works if the trade is honest.

#Chat encryption

Chat content is encrypted before it leaves your device. What reaches Bloosh servers is ciphertext. Staff cannot read your conversations, and a copy of the database does not expose them in readable form.

Encryption keys are tied to your account and held by you. There is no administrative override that lets Bloosh decrypt on your behalf. The honest consequence: losing your keys means losing that data.

#Workspace isolation

Row-level security in the database scopes every row to the organisation (and, where relevant, to you). A member of one workspace cannot read another. Storage objects follow the same rules.

#Confirmations

The assistant proposes. It does not send mail, write a calendar event, or delete anything until you confirm the card. Drafts sit in the thread until you accept, edit or dismiss them.

#Retention

Zero data retention is the rule for content that leaves the workspace to a model provider: nothing is kept after the request that needed it, and nothing is used to train a model. Connected-account tokens are stored encrypted in a secrets vault, not in application tables.

OAuth scopes are the minimum needed for the feature you turned on — reading mail is separate from sending it. Disconnecting a service revokes the token.