What an AI teammate should not be allowed to do

An assistant that can only read is safe and mostly useless. An assistant that can do anything is useful for about a week, until it sends something it should not have. Almost everything interesting about building this product has been finding the line between those two, and the answer turned out to be less about intelligence than about defaults.

Here is the model we landed on. None of it is novel on its own; what matters is which way each switch points when nobody has touched it.

Connections start read-only

When you connect Slack or your CRM, the assistant can look and nothing else. Writing is off at the organisation level, and it stays off until an administrator turns it on deliberately. This sounds obvious and is not how most integrations work: the usual pattern is to request the broadest scope the API offers at connect time and sort out the rules later, because asking twice costs conversions.

The cost of doing it the other way is real. A new workspace cannot do anything impressive on day one. We took that trade because the alternative is that a tool acquires write access to a company's CRM during an onboarding flow nobody read.

Permissions are per action, not per app

"Can it write to Linear?" is the wrong question, because writing to Linear covers both adding a comment and closing someone's issue. Every individual action a tool exposes is its own setting: ask, always allow, or disabled.

• Commenting on an issue is a small, reversible thing most teams allow outright.
• Closing one changes what a team sees in their own tracker, and usually should ask.
• Deleting a file or removing someone from a channel is something we make the assistant state explicitly before it will even try.

Granularity is unglamorous and it is where the real safety lives. A single per-app toggle forces a choice between useless and dangerous.

Anything that leaves your workspace waits for a person

An email, a Slack message to a customer, a record written into your CRM — these get drafted and then held. Somebody approves them before they go. There is no auto-approve mode in the product. Not one behind a plan, not one behind a flag, not one an administrator can switch on for convenience.

We have been asked for one. The argument against is simple: the moment it exists, the interesting question stops being whether the assistant is trustworthy and starts being whether the person who enabled it understood what they were enabling. We would rather the product be slightly more annoying and never be the reason a wrong email went out.

The part that is not solved

Per-item permissions are the honest gap. For some sources we can work out who is allowed to see each individual document and filter accordingly. For others the API simply does not tell an integration who may see what, so content is visible to everyone in the workspace. That is a boundary in someone else's product, not a shortcut in ours, but the effect on you is the same and it belongs on the security page rather than in a footnote.

If you are evaluating anything in this category, that is the question worth asking: not whether it is secure, but which parts are and which parts are not, and whether they will tell you without being asked twice.