KoltrixLeast privilege for AI email agents in a team workspace
An admin playbook for AI email agents: inherit user mailbox access, keep a workspace off switch, cut access on removal, scope by task, wall off sensitive mail.
On this page(10 sections)
- Principle 1: An agent should never see more than its user
- Principle 2: Limit what the agent can do, not just what it can see
- Principle 3: Keep a workspace-level off switch
- Principle 4: Removal means removal
- Principle 5: Scope by task where you can
- Principle 6: Separate sensitive mail from shared mail
- Principle 7: Log it, and look at the log
- How this maps to Koltrix
- A one-page policy you can adapt
- Key takeaways
When one person connects an AI assistant to their own inbox, the risk is mostly theirs. When a whole team does it inside a shared workspace, the assistant can end up reaching mailboxes, threads and customers that no single person was thinking about.
Least privilege is the old security idea that every user and system should have exactly the access it needs and no more. This playbook applies it to AI email agents from the point of view of whoever administers the team's email.
Principle 1: An agent should never see more than its user
The simplest and most important rule. An AI assistant acting for a person should inherit that person's mailbox access exactly, not a broader "workspace" or "admin" view.
In practice that means:
- If Priya can see support@ and her own inbox, her assistant can see support@ and her own inbox.
- If Priya can't see billing@, neither can her assistant, even if the integration technically could.
- If Priya's access changes, the assistant's access changes with it, immediately.
Watch out for integrations that connect with a service account or an admin token. Those often bypass per-mailbox permissions entirely, so one person's assistant can read everything.
Check for any tool you allow: does it enforce the same per-mailbox permissions as the email app itself?
Principle 2: Limit what the agent can do, not just what it can see
Access has two dimensions: which mailboxes, and which actions. Even within the mailboxes a user can see, an assistant doesn't need every action.
| Action | Typical need | Recommendation |
|---|---|---|
| Read and search | High | Allow |
| Label, archive, mark read | Medium | Allow (reversible) |
| Create drafts | High | Allow (inert until reviewed) |
| Send or forward | Low for assistants | Block; keep sending a human action |
| Permanently delete | Very low | Block |
| Change settings, rules, forwarding | Very low | Block |
Blocking send and forward matters most. Any email a teammate receives can contain text aimed at the AI. If the agent can't send or forward, a malicious email can't turn the agent into a way to exfiltrate data.
That last row deserves attention too. An agent that can create a forwarding rule can quietly copy all future mail to an outside address. That's a classic attacker move, and AI agents shouldn't have it.
Principle 3: Keep a workspace-level off switch
As the admin, you need to be able to turn AI connections off for the whole workspace, quickly, without chasing each person individually. Reasons you might need to:
- A security concern with an AI provider.
- A customer contract that restricts where their data can be processed.
- An incident where you don't yet know what happened.
The switch should take effect immediately, so that existing connections stop working at once rather than at the next sign-in. Test it once when things are calm so you know how it behaves.
Principle 4: Removal means removal
When someone leaves the team, or is suspended, every AI connection they made should stop working at the same moment their own access does.
Add this to your offboarding checklist explicitly:
Offboarding - AI connections
[ ] User removed from workspace / account suspended
[ ] Confirm their connected AI apps no longer have access
[ ] Revoke any tokens they created for integrations
[ ] Check for forwarding rules or filters they set up
[ ] Reassign threads and drafts they owned
The risk isn't usually malice. It's an old laptop with an AI app still signed in, or a personal assistant account that keeps a token alive long after the person has moved on.
Principle 5: Scope by task where you can
Not every use of AI needs the same access. If your team uses an assistant for a narrow job, scope it to that job:
- Inbox cleanup for one person: their own mailbox, organize actions only.
- Support drafting: support@, read and draft.
- Weekly summaries for a founder: read only.
Some tools let users choose permissions on the consent screen. Encourage people to approve only what their task requires, even if the default asks for more.
Principle 6: Separate sensitive mail from shared mail
The cleanest way to keep sensitive email away from AI tools is structural. Put it in mailboxes that only a few people can access, and that those people don't connect to AI assistants.
Typical candidates:
- HR and people matters
- Legal and contract negotiations
- Security disclosures and incident communications
- Finance with bank details, tax IDs, or payroll
With per-mailbox permissions, a support agent's assistant can help with support@ while having no path to hr@. That's far more reliable than asking everyone to remember not to paste certain things into a chat.
Principle 7: Log it, and look at the log
Every action an agent takes should be recorded: which tool, which user, which thread, when. Logs don't need email content to be useful.
A light review routine works for most small teams:
- Once a month, scan for unusual patterns: a spike in actions, actions at odd hours, actions in mailboxes that user rarely touches.
- After any incident or offboarding, check the log for that user's connections.
How this maps to Koltrix
In Koltrix, shared mailboxes have per-mailbox permissions, and the MCP server that connects Claude, ChatGPT and other assistants can read, organize and draft but never send. Per-mailbox permissions make principle 6 a matter of configuration, and the no-send rule covers principle 2 by design. The rest are habits worth building whatever tools you use.
A one-page policy you can adapt
AI agents in our workspace
- Assistants act with the user's own mailbox access, never more.
- Allowed: read, search, label, archive, draft.
- Not allowed: send, forward, delete, change rules or forwarding.
- hr@, legal@ and finance mailboxes are not connected to AI tools.
- Admin can disable AI access workspace-wide at any time.
- Leaving the team ends all AI access immediately.
- Agent actions are logged and reviewed monthly.
Key takeaways
- An AI agent should inherit its user's mailbox access exactly, never broader.
- Limit actions as well as visibility; block send, forward, delete, and rule changes.
- Keep a workspace-wide off switch and confirm it works before you need it.
- Make AI connections part of offboarding, so removal cuts access at once.
- Keep sensitive mail in restricted mailboxes that aren't connected to AI tools, and review agent logs regularly.
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.
