Gmail controls for AI agents

The control gap

Mailbox credentials combine sensitive reads with outbound communication and account configuration actions.

Mailbox permissions combine sensitive reading, drafting, sending, label changes, forwarding, and account configuration. Policy should identify the mailbox, thread, final To/CC/BCC recipients, external domains, attachment classifications, bulk count, and whether the action changes forwarding or delegation. OAuth scopes remain necessary but are usually too broad to express that final envelope.

Authorize sending after the draft is complete. Bind approval to recipients, subject, body and attachment digests, mailbox, and purpose so the agent cannot reuse it for a different message. Record the provider message ID and delivery result without storing message bodies in the authorization ledger. Endram can govern the action through its API; a dedicated Gmail execution adapter should not be implied until its provider-path tests exist.

What good looks like

Routine Gmail work continues automatically while sensitive actions are denied or held for a named reviewer.

• Classify read_thread and draft_email separately from send_email and change_forwarding.
• Scope policy to mailbox, recipient domain, thread instead of granting one undifferentiated Gmail capability.
• Require mailbox-owner approval for external sends, new recipient domains, forwarding, and bulk actions.
• Preserve the delegated user, agent, request payload hash, decision, reason, and policy version.

A production workflow

1. The agent asks Endram to evaluate a Gmail action before execution.
2. Endram matches the agent, delegated user, action, and target mailbox.
3. Low-risk requests proceed; sensitive requests create a time-bound approval.
4. The approved request executes once, and its outcome is attached to the original decision.

A policy you can test

Gmail high-impact approval is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: gmail-high-impact
match:
  tool: gmail
  action: ["send_email", "change_forwarding"]
  environment: production
decision: require_approval
approval:
  expires_in: 15m
  reviewers: ["security-on-call"]

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• A searchable record of attempted read_thread and change_forwarding operations.
• The exact mailbox and thread targeted by each request.
• Which policy version matched and why the request was allowed, denied, or escalated.
• Who approved the action, when approval expired, and whether execution succeeded.

Buyer checklist

• Which Gmail actions must never run without a human?
• Can policy restrict individual mailbox or recipient domain or thread?
• How are user delegation and service credentials represented?
• What evidence will incident response need after an unexpected action?