An AI agent that can send mail can create business consequences even when every message passes SPF, DKIM and DMARC. Authentication addresses aspects of sending-domain identity; it does not establish that the message was authorized, accurate or appropriate. Govern the send action as a separate capability with a defined purpose and recipient scope.
Define what the agent may communicate
Specify approved use cases, sending account, recipient sources, volume limits, attachment rules and review requirements. Routine internal status summaries and contractual commitments should not share the same autonomous approval path. Restrict external recipients and sensitive content according to the organisation's policy, and establish who can change that policy.
Derive recipient identity from a trusted directory or an explicitly approved address, not from an instruction embedded in an email being analyzed. A message saying send the report to this new address is evidence to evaluate, not automatic authorization. OWASP Prompt Injection explains why external text can manipulate agent behavior if it is treated as instruction.
Keep send authority separate from reading
Use a sending identity with only the necessary mailbox and API permissions. A report-reading integration should not silently gain send-as or send-on-behalf authority. Keep draft generation, approval and submission as separate logged events. Before submission, recheck recipients, subject, body and attachments against the approved version.
OWASP Excessive Agency recommends limiting exposed functions and permissions and enforcing authorization downstream. Apply those controls at the send gateway so a model cannot bypass them with a generic HTTP tool or alternate mail API. Rate limits and a kill switch reduce impact but do not substitute for recipient and content authorization.
Test a bounded sending workflow
For written plan SEND-01, assume tenant-A/service-mailbox, From status@example.invalid, recipient ops@example.invalid, subject Routine status, body Review complete; no change proposed, no attachments, purpose internal status. All identities are illustrative and no credential or actual approval is supplied.
Under a proposed gateway rule, the exact object with valid protected approval and an unused operation ID could become eligible for submission. A new external recipient, attachment, contractual purpose, changed body, changed From, different account or reused operation ID must stop it. A generic HTTP route must not bypass the same authorization boundary. These are expected decisions, not executed tests.
In production, distinguish a provider-accepted request from recipient delivery. If the send response is lost, inspect available message or operation identifiers before retrying to avoid duplicate mail. Provider idempotency support varies; a local replay guard alone cannot prove exactly-once delivery across a network failure.
Keep an inspectable action chain
The proposed sequence is approved report retrieval, draft creation, authorized human decision, execution-gateway validation, provider submission and separate delivery observation. Record which component owns each step. Provider request ID, approval receipt, submission timestamp and delivery result are unavailable in this example. No provider adapter, local guard or replay test ran, and no message was sent.
Authenticate and audit the actual mail path
Configure the sending service's documented authentication for the chosen From domain and verify authorized test messages at receivers. RFC 9989 explains alignment, while DKIM separates signer responsibility from the purported author. Neither protocol certifies the truth of an AI-generated statement.
Retain the user or service authorization, approved content version, recipient resolution, submission result and subsequent delivery evidence under appropriate retention controls. Provide a way to suspend sending immediately without disabling read-only diagnosis. If an unauthorized message is sent, treat it as a communication incident; fixing DNS will not retract its contents.