Agent email security

Give a workflow only the mailboxes and tools it needs. Use mailbox-scoped API keys where possible. Keep credentials in server-side secret storage, never in a public repository, browser bundle, email body or agent conversation.

To rotate a key, create a replacement, update the runtime, confirm it works and revoke the old key. Remove unused credentials when retiring an agent or integration. Keep tenant and mailbox ownership checks in application code rather than relying on a prompt to enforce them.

Separate reading and drafting from approval to send, disclose private data, spend money or modify accounts. Decide which actions require human review before enabling unattended processing.

An email can contain instructions aimed at changing the agent's behavior: ignore previous rules, reveal secrets, call an unrelated tool or send data to a new address. The same instructions may appear in a quoted reply, HTML, a link or an attachment.

Pass email to the model as task data, clearly separated from trusted system instructions. Restrict available tools and validate each proposed action against application policy. Check recipients independently, limit which records may be retrieved and require approval for sensitive actions. An instruction to forward a whole mailbox must not expand the agent's access.

Webhook HMAC verification establishes that the webhook was delivered with the configured secret. It does not make the original sender, email contents or requested action trustworthy. Similarly, SPF/DKIM/DMARC results are not business authorization.

Test with adversarial messages as well as normal ones. Log enough metadata to investigate outcomes without retaining unnecessary sensitive content.

Verify X-Robotomail-Signature using HMAC-SHA256 over the exact raw request body and the webhook secret. Compare signatures safely, reject invalid requests and only then parse the event. Re-serializing a JSON object can change the bytes and break verification.

Deduplicate accepted events or their resulting business actions. A retried notification must not create another ticket or send another reply. Use a queue for slow work and keep processing state outside the model.

This signature procedure applies to webhook delivery. Do not claim that polling responses or SSE frames carry the same webhook signature. Follow the webhook reference for implementation details.

Treat file names, declared MIME types and file contents as untrusted. Apply size and file-type limits appropriate to your application, avoid automatic execution and isolate document conversion or extraction. Do not let a file path from an email select an arbitrary location on your server.

Fetch attachment download URLs only when needed and avoid exposing them in public logs. A signed URL grants temporary access to the resource; keep it out of unrelated chats or analytics. If your workflow requires malware scanning, integrate and verify that control explicitly. Do not assume a Robotomail download is a malware-scan verdict or that the product provides quarantine.

Email HTML and remote images can also reveal information or include deceptive links. Render using a safe viewer and avoid automatically following links or loading remote resources solely because a model requests them.

Define which messages, extracted fields, attachments and logs the workflow needs, who can access them and how long they should be kept. An operational mailbox and a legally controlled archive serve different purposes.

If your application needs an archive, retrieve authorized messages and attachments through the documented APIs and store them using controls you operate. Account for pagination, attachment URL expiry, incomplete downloads, access restrictions and restore testing. Do not describe that process as immutable, tamper-proof or compliant with a legal-hold requirement without implementing and verifying the required controls.

Robotomail account deletion is a separate operation from exporting or managing an individual application's record lifecycle. Check the account API and privacy policy for the current behavior. Do not assume undocumented per-message deletion or bulk export endpoints exist.

Map the data flowing through the mailbox, your application, model provider, logs and any connected tools. Minimize the information sent to each processor and restrict access to conversation content. Decide how your application will handle access, correction, deletion and retention requests before processing sensitive workloads.

Review the current privacy policy, terms and the agreements relevant to your organization. Use contact to confirm contractual, location, retention or security requirements that are material to your use case. This guide does not claim that using an email API by itself makes an application GDPR-compliant or supplies a particular DPA, residency commitment or certification.

Keep production content out of development fixtures unless there is an authorized and controlled reason to use it. Prefer synthetic conversations for integration and adversarial tests.