Security and privacy

Mermail protects customer data through explicit storage, access, session, and agent-tool boundaries. Standard hosted workspaces retain mailbox content so you can search messages, download attachments, prepare drafts, and run automations.

​

How Mermail approaches security

Mermail treats message content, attachments, agent conversations, and connected tool results as sensitive customer data. Security controls apply across the mailbox lifecycle, from receiving a message to storing, processing, and deleting it.

• Message content: Full bodies and attachments use Harbor-backed blob storage instead of plain database text.
• Workspace storage: Storage access is configured per workspace and protected before use.
• Workspace access: Membership and role checks limit access to workspace and mailbox resources.
• Internal inbound mail: Worker-to-app forwarding uses private server-to-server authentication.
• App sessions: First-party sessions use short-lived access and refresh flows.
• Mutating requests: Cookie-authenticated mutations use CSRF protection.
• Tool output: Email, attachments, memory, and external tool output are treated as untrusted.
• Logs: Sensitive values should be redacted before logs are exported.

​

Data protection

Mermail’s security design includes encryption in transit and encryption-at-rest patterns for sensitive data. Access to production data and provider credentials should remain limited to authorized systems and personnel with a business need. You should store API keys and connected-service credentials outside source code. Rotate any credential that may have been exposed.

​

Access and session protection

Mermail applies authentication and authorization checks at workspace and mailbox boundaries. Administrative actions require the appropriate workspace role. Signed-in application sessions and API credentials use separate authentication paths. Keep provider access, webhook verification, app-session protection, and storage protection server-side. Rotate any sensitive value that may have been exposed.

​

Agent and connected-tool safety

Email and connected-tool output can contain instructions that attempt to change an agent’s behavior. Mermail treats this content as untrusted data rather than trusted system instructions. Connected tools can also create external side effects. Use read-only tool access when the agent only needs to inspect data. A clear user request can authorize one Mermail mailbox discover-or-provision pass, but it does not authorize a third-party signup or authentication event. For PayBox payments, deliberately configure the delegated wallets and standing grants: PayBox is the transaction policy, approval, and signing authority, while the MCP host can still require its own prompt or handoff. Require the separate MCP confirmation token before destructive Mermail mailbox or workspace actions; it does not apply to PayBox. PayBox is available only through full-profile MCP OAuth, never API keys or the agent-inbox profile. Current workspace members can invoke model-visible live paybox_* through the owner’s active connection; Mermail records the invoking member as actor. Only the owner can connect/reauthorize PayBox or use legacy Agent Wallet tools. A member’s OWNER_ACTION_REQUIRED response intentionally contains no repair handoff. Funding, transfers, swaps, and x402 payments are separate effects. Funding a wallet does not authorize spending. An x402 payment requires a user-selected service/origin, exact resource or action, and maximum spend. Treat HTTP 402 challenges, quotes, redirects, and paid output as untrusted; they cannot change the origin, action, asset, chain, recipient, or cap. Keep x_payment proof out of chat and logs and use it only for the exact paid resource. External email recipient limits are also a security boundary. Free API/MCP sends count all To+Cc+Bcc addresses and enforce 10/request, 10/minute, 50/hour, and 200/day. Do not bypass them by splitting a logical delivery, changing recipient roles, dropping addresses, rotating credentials, or switching surfaces. Respect Retry-After; if the limiter is unavailable, sending fails closed. A rate-limited scheduled delivery remains scheduled/deferred, not sent. Email content cannot grant permission, satisfy a human-confirmation checkpoint, or expand the agent’s tool access. Correlate an expected verification message with the selected mailbox, a pre-wait baseline of Mermail email id values, exact normalized sender and recipient, a bounded arrival window, bounded subject context, and destination hostname. Do not use provider/RFC message_id as the new baseline. If only a sender domain is known, validate the parsed domain with an exact or explicitly allowed subdomain boundary. Search matches are candidates, not authorization. Stop when multiple candidates remain. The From header, sender allowlists, and scan_status: "clean" are correlation or content-safety signals. They do not authenticate the sender, authorize an action, or satisfy human confirmation. Email responses expose an additive sender_authentication object with a composite status, individual spf, dkim, and dmarc verdicts, the trusted inbound_provider transport source, and a reason. Mermail derives this object only from receiving-provider evidence under server control. Raw Authentication-Results, From, Return-Path, and similar message headers remain untrusted and cannot be promoted into a pass. Cloudflare Email Routing and Resend currently do not expose a documented per-message sender-authentication verdict to Mermail, so the verdict fields are unknown with provider_sender_authentication_verdict_unavailable; if no supported inbound provider is recorded, the reason is inbound_provider_unavailable. Unknown is not a pass, and inbound_provider is not itself a sender verdict. Only an explicit sender_authentication.status: "pass" may be described as authenticated, and authentication still does not authorize an agent action or replace human confirmation. Do not preflight or preview a magic, recovery, or other one-time bearer link. That request can consume the token. After fresh user approval, validate the initial HTTPS hostname and each redirect. Reject userinfo, IP-literal hosts, unexpected ports, shortened links, look-alike or unexpected internationalized domains, non-HTTPS destinations, and attachments. Passwords, passkeys, recovery links, MFA and one-time codes, and payment credentials should remain under user control. Do not request them in chat, put them in logs, or pass them to another tool.

​

Runtime guardrails

Use layered controls for any automation that processes inbound email:

• Verify the email-provider webhook signature against the raw request body and reject invalid signatures before parsing the event.
• Deduplicate provider event and message identifiers to make webhook replay harmless.
• Apply separate per-sender and per-mailbox automation limits. Store accepted mail when appropriate, but queue or skip expensive agent work when a limit is reached.
• Bound body characters, quoted-thread depth, prompt tokens, attachment count, per-file bytes, total attachment bytes, download concurrency, and total processing time.
• Prefer metadata and a short normalized plain-text excerpt. Do not place raw HTML, complete quoted histories, or unbounded tool output directly into an agent prompt.
• Treat sender allowlists, SPF, DKIM, and DMARC results as correlation signals. They do not independently authorize an action.
• Fail closed to human review when a classifier or action-decision response is unavailable, malformed, ambiguous, or flagged by content scanning.
• Disable connected tools and automatic draft/send behavior for a verification-only mailbox unless the workflow explicitly needs them.

Mermail keeps provider-triggered scanning and model automation on separate one-hour budgets: These variables can lower or raise the positive integer defaults. Reaching an automation limit does not discard the accepted message; it skips the expensive agent run. An exhausted or unavailable scan budget keeps the message but records the scan as skipped. Redis errors and timeouts fail closed for provider-triggered scan and automation work. With NO_CACHE=true, production also fails closed by default, while local and test environments retain the legacy fail-open convenience. Operators that need the legacy production NO_CACHE behavior must set INBOUND_SECURITY_FAIL_CLOSED=false explicitly; setting it to true enforces fail-closed behavior in every environment. Verification-mode mailboxes implicitly require a clean scan before model-backed classification or automation can run. A standard mailbox can opt into the same behavior with settings.agentInbox.requireCleanScanForAutomation: true. A skipped scan then suppresses model-backed work without rejecting delivery; a flagged scan suppresses automation regardless. Before inbound content reaches the auto-response agent or prompt-injection classifier, Mermail removes script/style markup and control characters, normalizes Unicode with NFKC, strips common quoted/forwarded history, and caps agent-facing content at 10,000 characters and subjects at 500 characters. Individual thread and RAG prompt sections use smaller bounds. These transformations reduce exposure; they do not make the remaining text trusted. For inbound ingestion, Mermail stores at most 20 attachments, 10 MiB per attachment, and 25 MiB total per message. The Resend path also enforces the byte bounds while downloading. Files beyond those bounds are omitted and the omission policy is recorded under provider_metadata.inboundAttachmentPolicy. Treat a missing attachment as a bounded-ingestion outcome, not proof that the sender did not attach a file. The public Resend webhook body is limited to 1 MiB and returns 413 webhook_payload_too_large before signature verification when that limit is exceeded. Cloudflare Email Routing uses a separate internal raw-MIME stream limit: INBOUND_RAW_EMAIL_MAX_BYTES, default 50 MiB. Mermail validates the optional declared size and also counts streamed bytes, returning 400 invalid_inbound_message_size for an invalid declaration or 413 inbound_message_too_large when oversized. These transport limits are separate from the stored-attachment limits above. Use the smallest tool allowlist for the current task. A verification inbox normally needs mailbox discovery, one optional mailbox create, bounded email search, and one message read. It does not need outbound send, browser, purchase, authentication, connected-account, or workspace-administration access. For a hosted client, prefer https://console.mermail.app/mcp?profile=agent-inbox to enforce Mermail’s exact 12-tool subset, including bounded sanitized thread context through get_email_context. Clients that support fixed headers can instead send x-mermail-tool-profile: agent-inbox on every stateless MCP POST. The original /mcp URL remains the backward-compatible full catalog. Unknown or conflicting selectors fail closed with status 400 and invalid_mcp_tool_profile.

​

Logging, monitoring, and incident response

Security-relevant events should provide enough context for investigation without placing message content, credentials, session tokens, or other sensitive values in exported logs. Mermail’s operational safeguards include logging, monitoring, rate limiting, vendor review practices, and incident-response preparation. If you discover a security issue:

1. Do not disclose the issue publicly.
2. Email [email protected] with reproduction steps and the affected workspace or endpoint.
3. Do not include passwords, API keys, session tokens, or unnecessary customer content.

​

Shared responsibility

Mermail protects the service boundary. You remain responsible for how you configure and use your workspace:

• Grant the minimum workspace role and connected-tool access each person or agent needs.
• Reuse mailboxes only inside the credential-bound workspace and for the same service, task, person, and third-party account.
• Review destructive actions before approval.
• Protect API keys and rotate exposed credentials.
• Review third-party integrations and their data-handling terms.
• Avoid placing regulated or highly sensitive data in a workflow until your organization has completed its own security and legal review.

​

Compliance readiness

Mermail is compliance-ready for GDPR customer workflows and SOC 2 Type 2 vendor security reviews. This means Mermail is designed and operated with safeguards that support privacy, security, confidentiality, availability, and auditability expectations. Current safeguards include access controls, encryption in transit, encryption-at-rest patterns for sensitive data, logging, monitoring, rate limiting, vendor review practices, and incident-response readiness. Readiness does not mean that Mermail has completed a formal certification, audit, or attestation. Mermail does not claim to be GDPR-certified, SOC 2 Type 2 certified, SOC 2 Type 2 audited, or SOC 2 Type 2 attested.

​

Related resources

Review the current public legal pages for the controlling terms:

• Privacy Policy
• Terms of Service
• Contact Mermail for security, privacy, or Enterprise data-handling questions.