Build the test around consequential actions
A useful red-team plan begins with the actions that could create harm: sending to an external recipient, forwarding an attachment, deleting evidence, changing labels that drive workflow, creating trusted-looking calendar events, or delegating mailbox-derived instructions to another tool. List those actions and the permissions needed for each before writing attack messages.
Test indirect instructions embedded in ordinary email
Use benign test messages that contain instructions such as forwarding a document, changing a recipient or invoking another workflow. The expected result is not that the agent magically recognizes every malicious sentence; it is that mailbox content cannot authorize consequential actions by itself. A separate instruction boundary and explicit approval should remain in control even when the message is persuasive.
Exercise data-exfiltration paths independently
Test message text and attachments as separate data classes. An agent might correctly refuse to copy a secret from a message body but still forward the original attachment. Test known external domains, newly introduced domains and recipient substitutions discovered through contacts. The policy should explain why each destination is allowed rather than trusting that a contact lookup made it legitimate.
Force high-fanout and retry edge cases
A safe workflow should resist a prompt that expands one action into dozens or hundreds of recipients. Test recipient ceilings, rate limits, duplicate actions and repeated retries. A human approval gate is much less useful if one approval silently authorizes an unbounded recipient set or recursive delegation to another sending tool.
Test delegated tools as a new trust boundary
When an email agent can call a CRM, calendar, filesystem or another agent, mailbox content can influence a much larger environment. Pass only the structured fields needed for the next task and preserve the identity of the originating request. Red-team the transition itself: the downstream tool should not receive the full untrusted message when a narrow field such as a date or ticket number is sufficient.
Record the controls that stopped each scenario
The useful output of red-teaming is not a single safety score. Record which boundary stopped each scenario: human approval, verified recipient policy, attachment release control, untrusted-content separation, rate limiting or an audit requirement. Re-run the same deterministic scenarios after permission changes so an expanded scope cannot enter production without an explicit review.
Verify the evidence
Use the live analysis that matches this workflow instead of relying on a generic status check.