How to Set Up AI Email Governance Policies

Start with four questions

Before writing any rule, answer these for each AI client you connect:

• Which mailboxes and labels should it be able to read?
• Should it be able to send, or only draft?
• What must be stripped from a message before the model sees it?
• Who or what is off limits entirely?

The three policies below are common answers. With PortEden, each is enforced at the boundary between the AI client and the mail provider, so the rule holds even if the assistant is steered by a malicious message.

Policy 1: Read-only triage

The safest starting point. The assistant can read and summarize a specific mailbox but cannot send, forward, or delete anything. Configure read-only actions, scope it to the queue it serves (for example a shared support or sales inbox), set a time window such as the last 30 days, and redact PII on read so the model summarizes without seeing raw account numbers. This unlocks most of the value of an email assistant with almost none of the risk.

Policy 2: Draft-only assistant

The next step up. The assistant can compose replies, but a human reviews and sends them. Enable drafting, require confirm-before-send so nothing leaves without approval, and keep redaction on. This is the policy that would have prevented the widely reported incidents where an assistant sent or deleted mail on its own: a human stays in the loop on anything that leaves the building.

Policy 3: Protected mailboxes

Some inboxes should never be in scope. Executive, legal, HR, and anything under privilege or NDA can be excluded globally, so no assistant, under any other policy, can read them. Add contact and domain rules to hide specific senders or recipients even within in-scope mailboxes. This is the rule that contains lateral exposure: an assistant on the sales inbox never inadvertently surfaces a forwarded legal thread.

A staged rollout

• Week 1: connect one mailbox under read-only triage with redaction on. Watch the audit trail.
• Week 2: add draft-only with confirm-before-send for a single team, and review what it drafts.
• Week 3: codify protected mailboxes and contact rules globally, then expand to more teams.
• Ongoing: review the audit trail on a regular cadence and tighten any policy that proved too broad.

An audit checklist

• Every AI client maps to a named policy, not an ad-hoc grant.
• Send and delete require human approval where they are allowed at all.
• Protected mailboxes are excluded globally and verified.
• PII is redacted on read and the redaction is logged.
• Every read, draft, and send is attributable to a user and an AI client.
• You can revoke any assistant's access in one action.

For the broader risk picture, see the risks of connecting email to AI and how this differs from AI email security providers.