Gmail
10 reviewed Dtwo policies for Gmail MCP servers — egress + ingress controls for governing what AI agents can do with Gmail.
On this page
Reusable DTwo policies for Gmail MCP servers. The Gmail MCP surface spans three common implementations — the official Google remote server behind Anthropic's Claude Gmail connector (draft-only, no send/delete/filter tools by design), the archived-but-widely-deployed GongRzhe community server, and the actively maintained taylorwilsdon Workspace server — which between them expose read, draft, send, label, filter, and permanent-delete tools under divergent naming vocabularies. That divergence is the risk profile: a tenant migrating from the Claude connector to a community server silently gains external send, permanent delete, local-file attachment exfiltration, and auto-forward filter persistence, so these policies deny-by-default and match on tool-name suffix across all three vocabularies.
Available policies
| Policy | Direction | Purpose | Framework bundles |
|---|---|---|---|
| cap-bulk-export | ingress | Deny batch content reads above the ID-array cap and clamp search maxResults, throttling mass mailbox harvesting. |
soc2, hipaa, gdpr-ccpa |
| filter-blocked-senders | egress | Strip messages from listed senders or domains out of mailbox reads; a thread left with nothing is dropped (transform-only). | — |
| filter-dormant-threads | egress | Empty direct thread/message reads of conversations with no recent activity; one recent message keeps the whole thread (transform-only). | — |
| filter-labeled-threads | egress | Withhold whole threads carrying a restricted Gmail label — a one-click manual override for sensitive conversations (transform-only). | — |
| freeze-destructive-ops | ingress | Deny permanent email, label, and filter deletion for every caller; reversible label/archive operations pass through. | soc2, hipaa, gdpr-ccpa, sox |
| guard-external-send | ingress | Deny send-class calls when any to/cc/bcc recipient falls outside the corporate-domain allowlist; the agent is told to draft instead. |
soc2, hipaa, gdpr-ccpa, sox |
| guard-mailbox-persistence | ingress | Block Gmail filter creation, the classic auto-forward / auto-delete exfiltration-persistence primitive. | — |
| mask-pan-egress | egress | Mask payment-card-number shapes in email content returned to agents by mailbox-read tools (transform-only). | pci-dss, gdpr-ccpa |
| recent-search-only | ingress | Rewrite thread searches to prepend a newer_than: recency term, so Gmail itself returns only recent correspondence (transform-only). |
— |
| role-gate-writes | ingress | Make Gmail read-only by default: verified read tools pass for everyone, every write/send/label/filter/delete tool is denied. | soc2, hipaa, pci-dss, gdpr-ccpa, sox |
Tool naming on the DTwo gateway
DTwo prefixes tool names with the MCP server name configured on the gateway, and the three Gmail servers use unrelated naming conventions — Google/Claude uses bare thread-centric names (search_threads, get_thread), GongRzhe uses bare message-centric names (send_email, read_email), and taylorwilsdon uses a *_gmail_* infix (send_gmail_message). The policies in this directory match on the suffix (send_email, send_gmail_message, delete_email, create_filter, etc.) and deliberately cover all three vocabularies so they stay portable across servers and gateway prefixes. Always confirm the exact tool name your gateway sends using the dump-input debug technique before deploying, especially if your server uses camelCase or renamed tools that the snake_case suffix matchers will not catch.
Identity claims
Most policies here require no IdP claims. role-gate-writes is group-gated: write access is granted via input.subject.claims.groups, and the group names in the policy are placeholders — replace them with your IdP's group names at import time. Missing or malformed claims fail closed (no group → no write access). The remaining policies apply to every caller by design (a mailbox record must survive agent error and prompt injection regardless of who is driving the agent).
Contributing
To add a Gmail policy:
- Create
apps/gmail/<policy-slug>/withpolicy.mdand atests.yamltest file. - Add a row to the table above.
- Declare
apps: ["gmail"]in the policy frontmatter, plus any industry / bundle slugs that apply. - If the policy fits a framework bundle (e.g.
soc2,hipaa,pci-dss,gdpr-ccpa,sox), link to it from the matching landing page. - Run
pnpm manifestfrom the repo root.
See CONTRIBUTING.md for the full process.