A company running on Microsoft 365 has already written everything in Teams
Established European companies rarely run on Slack. They run on Teams, which usually arrived alongside the office suite, and their team channels hold years of how the company actually works. How it is supposed to work sleeps in a document nobody reopens.
An AI plugged into that company without its channels is a consultant who has read the org chart and nothing else. It will be polite, general and wrong on the first precise question. The real cost is not the price of the model, it is the number of times someone has to redo its answer.
No Teams channel becomes readable company-wide
This is the sharpest difference with the other big team messenger. In Slack, a public channel is already open to the entire workspace, and your Kastel files it where it already sits, at company level. We say so plainly on the Slack page.
Teams has no such notion. A standard channel belongs to a team, and a team has named members. The Teams connector treats that membership as the read permission: a channel's content is filed under the department its members belong to, never at company level, even when the channel is open to the whole team.
Channels, and nothing that looks like a private chat
The Teams connector addresses one precise surface of Microsoft 365, the channels. The rest of Teams does not interest it.
Private conversations are not read and then discarded. The connector never asks Microsoft for the list of your chats, so it does not even know they exist.
Who can read what once Teams is connected
Every row can be checked in Teams itself, by opening the channel and looking at who belongs to it.
| In Teams | Who can read it through a connected AI |
|---|---|
| A team's standard channel | People in the department the team's members belong to |
| A team's private channel | People in the department that channel's members belong to |
| A channel whose members span several departments | Nobody, until an administrator decides where it belongs |
| A channel with a member your organisation does not know | Nobody, until an administrator decides |
| A one-to-one chat, a group chat | Nobody. Those conversations are never read |
The fourth row surprises people, and it is deliberate. An unidentified member is a doubt, and a doubt closes rather than opens. It is the same rule that governs who is allowed to see what when an AI plugs in.
When someone leaves a team, the reading closes behind them
A channel's scope is not computed once and for all at connection time. It is recomputed on every synchronisation pass, from the membership list as it stands then.
When that list changes, the channel is re-read in full so that messages already taken in are refiled under the new scope. A departure therefore closes access to that channel's older conversations too, not only to new ones. This is the case that costs the most to get right, and the one that leaks almost everywhere else.
What this connector does not do
The authorisation is not a personal gesture. It is granted once, at the level of your Microsoft 365 organisation, by an administrator. If your IT department says no, this connector does not work, and nothing on the Kastel side changes that. In exchange, if you have already connected Microsoft 365 for mail and documents, Teams reuses the same Microsoft app and the same token, with no second authorisation to request.
Kastel takes no part in your conversations. It posts no message, reacts to nothing, joins no meeting, and the Microsoft permissions it requests are refused at construction time if any of them looks like a write.
A membership change costs a full re-read of the channel concerned, so the refresh is heavier that day. We prefer that cost to content left filed under a department the person has walked away from.
See what Kastel does with what your company knows.
The product page shows the whole mechanism, from connecting your tools to the moment an AI works on your knowledge without ever stepping outside its scope.
See the product
