Start with actions, not the model name
An email agent becomes risky because of the actions it can perform and the data it can reach, not because a particular model or protocol is inherently unsafe. Inventory read access, attachment access, draft creation, direct sending, external recipients, contact lookup, deletion, calendar creation and delegated tool calls separately. This creates a permission graph that can be reviewed even before a real mailbox or OAuth grant exists.
Combinations create more risk than individual permissions
Read-only access exposes information, while send-only access can transmit content supplied by the user. Combining mailbox read access with unrestricted external sending creates a direct exfiltration path. Adding attachment access, contact lookup or downstream tool delegation expands that path further. Review combinations as abuse paths rather than treating every scope as an isolated checkbox.
Treat retrieved email as untrusted data
A message body can contain instructions that look like a task for an agent. The authorization to act should come from the user or a trusted workflow boundary, not from text retrieved inside the mailbox. Keep retrieved content in a data channel, validate structured fields before acting, and avoid allowing a message to grant itself permission to send, forward, delete or invoke another tool.
External recipients deserve a separate control boundary
The difference between drafting a response and transmitting private content outside an organization is material. Use verified recipient or domain allowlists for narrow workflows and require explicit approval when a destination falls outside that set. Attachment release should be treated as another distinct decision because an attachment can contain substantially more sensitive information than the message text that triggered the action.
Limit fanout and preserve reversibility
Autonomous sending should have low recipient ceilings and rate limits so a single mistaken action cannot become a large incident. Prefer reversible mailbox changes such as labels or archive operations over deletion where the task allows it. When destructive actions are necessary, pair them with stronger approval and durable audit evidence.
Validate the permission model with adversarial scenarios
A permission review is a design artifact, not proof that an agent implementation resists prompt injection. Before granting production mailbox access, exercise the selected permissions against messages that request forwarding, recipient substitution, attachment release, mass sending and tool delegation. Mailybox’s Agent Mail Red-Team Sandbox turns the same permission graph into deterministic abuse-path scenarios without requiring access to Gmail or Microsoft 365.
Verify the evidence
Use the live analysis that matches this workflow instead of relying on a generic status check.