KoltrixShared mailboxes and MCP: setting up AI assistants for a team
An assistant has its owner's access, so shared-inbox permissions govern it automatically. Who connects, which admin switches matter, and a one-week rollout.
On this page(9 sections)
One person connecting an assistant to their own mail is a personal decision. A team doing it is a policy question. Who may connect? Which mailboxes can an assistant see? What happens when someone leaves? Who can turn it off?
Koltrix answers most of these with one design choice: an assistant has exactly the access of the person who connected it, no more. That makes team rollout simpler than it sounds. This post covers how shared mailboxes interact with MCP, a sensible setup for a small team, and the rules of thumb that keep it tidy.
The model in one sentence
An assistant connected over MCP acts as you. It sees the mailboxes you can open in Koltrix, checked on every call, and it never sees a mailbox you cannot.
That has useful consequences for shared inboxes.
| Situation | What the assistant sees |
|---|---|
You have access to support@ and sales@ |
Both, and it can search across them |
You have access to support@ only |
support@ only. sales@ is invisible |
An admin removes your access to support@ tomorrow |
The assistant loses it too, immediately |
| You are removed or suspended from the workspace | The connection stops working |
There is no separate "assistant permission list" to keep in sync with your people. Koltrix's per-mailbox permissions for the team inbox are the single source of truth, and the assistant inherits them.
Who connects
Each person connects their own Koltrix account. The connection belongs to that person, in that workspace. This matters for three reasons:
- Accountability. Actions are tied to a person's connection. The workspace audit log records connections, token renewals, revocations and tool calls, with the tool name and none of your mail.
- Revocation. If one person's laptop is lost, you revoke that person's connection without disturbing anyone else.
- Access follows roles. A new hire who only has access to
support@can connect an assistant that only seessupport@.
On Claude Team and Enterprise plans, an owner may need to add the Koltrix connector for the organization first, and then each member connects their own account. That is a Claude-side step, and the docs page covers it.
The admin controls
Workspace owners and admins have two switches, both in the AI assistants area of Koltrix settings.
- Assistants on or off for the workspace. Off means every connection stops working at once and no new ones can be made until it is turned back on.
- Allow assistants to send email after you confirm. This is off for every workspace until someone turns it on. It blocks sending immediately when turned off.
Sending needs three things before one message goes out: the workspace switch, the person's own opt-in on the approval page, and a yes on every message. Hard limits apply across the workspace: 20 sends a day per connection and 50 a day per workspace through assistants, at most 10 recipients per message, no Bcc and no attachments. Admin guide: turning assistants and sending on or off covers the decisions.
For most teams, the right starting point is: assistants on, sending off. People get the reading, organizing and drafting benefits, and a human still presses Send.
A rollout for a small team
You do not need a project plan. A week is enough.
| Step | Who | What |
|---|---|---|
| 1 | Admin | Check that assistants are on and sending is off |
| 2 | Admin | Agree on a shared label vocabulary (see below) |
| 3 | One person | Connect, try triage and drafting for two days |
| 4 | That person | Share what worked in a short note with the exact prompts |
| 5 | Everyone | Connect, using the shared prompts |
| 6 | Admin | After a week, review who has connected and what they are using |
Starting with one person means the first mistakes are made by someone who expects to make them.
Shared labels are the team's vocabulary
An assistant is far more useful when the team agrees on labels. "Label this Needs-Legal" works if everyone means the same thing, and "show me everything labeled Needs-Legal" works across people.
A few conventions that hold up:
- Few labels, clear names. Eight clear labels beat thirty overlapping ones.
- State labels, not topic labels, for workflow. "Waiting on customer" and "Needs reply" are more useful for a team than topic labels.
- Put the label list in your shared prompts. If the assistant is told the labels, it uses them. Otherwise, a label name that does not exist yet is created, which is how people end up with
Receipts,receiptsandReciepts.
An assistant can list the workspace's labels, so "check my labels before labeling anything" is a reasonable standing instruction.
Drafts and ownership
An assistant saves drafts to your Drafts folder, under your access. That makes the author clear: the draft is yours, and you decide to edit, send or discard it. For shared inboxes, decide the team convention:
- Who sends from
support@? The person who owns the reply, same as without an assistant. - Which address is the From? An assistant can list the mailboxes you may use, and the draft takes a From mailbox. If it is not specified, Koltrix uses the mailbox the conversation was addressed to, or your first one. Ask people to name the mailbox when it matters, or review the From on the draft.
- Where is the review step? Treat an assistant's draft like a junior colleague's: someone reads it before it goes. Reviewing AI-drafted replies has a checklist.
Koltrix's own in-app AI, the agents that sort and suggest replies inside the app, is separate. A person always clicks Send on what it suggests. The rules above apply only to assistants that people connect themselves.
When someone leaves
Offboarding has two parts, and Koltrix handles the first automatically.
- Removing them from the workspace. Their access ends immediately, and with it any connection they made.
- Reassigning what they were responsible for. Conversations in shared mailboxes belong to the workspace, not to a person. Check who was handling what and reassign it as you would without an assistant.
Mail an assistant read during their sessions was sent to that assistant's provider and handled under the provider's terms. That is a reason to keep the most sensitive mailboxes behind narrower access in the first place.
Rules of thumb
- Start narrow. Grant mailbox access by need, then let the assistant inherit it.
- Keep sending off until someone has a concrete need and a plan to review.
- Write the shared prompts down. Teams that share prompts converge on the same quality.
- Review connections monthly. The list is short, and old ones lapse after 30 days of inactivity anyway.
- Remember what leaves the building. The parts of your mail an assistant reads go to its provider and are handled under its terms. What your AI provider sees is worth sharing with the team.
Key takeaways
- An assistant has the access of the person who connected it, so per-mailbox permissions in Koltrix govern it automatically.
- Each person connects their own account, which keeps actions attributable and revocation surgical.
- Admins can switch assistants off for the whole workspace; sending is a separate switch that starts off.
- Agree on a small set of shared labels and share your best prompts.
- For a team-ready summary, see koltrix.com/mcp and the least-privilege guide.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
