Security

Disclosure policy, plainly.

How to report a vulnerability, what is in scope, how we respond. For our broader security posture, see /trust.

How to report

Email security@mails.ai with a clear writeup. Include: vulnerability summary, affected endpoint or surface, reproduction steps, your assessment of severity, and (if relevant) suggested remediation. We’ll publish a PGP key + fingerprint on this page when the formal disclosure program opens at Phase 1 launch — in the meantime, send the report in clear and we’ll move to a private channel quickly if warranted. Please do not file public issues, do not test against other customers’ data, and do not exfiltrate beyond what is needed to demonstrate the bug.

In scope

  • Authentication or authorization bypasses on api.mails.ai or app.mails.ai.
  • Cross-tenant data exposure (any customer reading another customer’s data).
  • Account takeover via email + DKIM/SPF/DMARC manipulation.
  • Prompt-injection scanner bypass that delivers high-risk-classified attacks to a customer’s webhook without quarantine.
  • Server-side request forgery, SQL injection, RCE, or arbitrary file read on any Mails.ai-controlled surface.
  • MCP server (npm-distributed @mailsai/mcp-server) credential or context leakage.
  • Reputation-graph manipulation that allows a sender to gain unwarranted Clean-pool placement at scale.

Out of scope

  • Self-XSS, missing security headers without exploitability proof, clickjacking on pages with no sensitive actions, denial-of-service via volumetric load.
  • Issues in third-party services (AWS, Stripe, Vercel, Cloudflare, Anthropic) not caused by our configuration — report directly to the vendor.
  • Social engineering of Mails.ai team members.
  • Physical attacks on infrastructure.
  • Spam delivered through the platform that the classifier correctly flagged but the customer disputes — this is an abuse-policy issue, not a security issue.

Our commitments to you

  • Acknowledge within one business day— you get a real human reply confirming receipt.
  • Triage within five business days— severity assessment + planned timeline.
  • Fix timeline based on severity: Critical — 7 days, High — 30 days, Medium — 90 days, Low — next major release.
  • Public disclosure coordination— we will not disclose details until you confirm a customer-side fix window has elapsed (or 90 days, whichever is sooner).
  • No legal action against good-faith research within this scope.

Recognition

No bounty program at closed beta. Validated reports get public credit at /security/hall-of-fame post-launch (with your consent, or anonymous if preferred). When the bounty program does launch, we will retroactively credit closed-beta-era valid disclosures.

Our threat model in brief

The four risk classes we worry about most:

  • Prompt injection RCE— the primary attack class our scanner exists to defend. See that post for the full threat model.
  • Cross-tenant exposure— the worst-case bug for any multi-tenant API. Per-workspace data isolation, per-key authorization, no shared tables.
  • Reputation laundering— bad actors trying to gain unwarranted sender reputation. Behavioral classifier auto-throttling, per-agent reputation graph, complaint auto-suspend at 0.3%.
  • Sub-processor breach— one of our vendors compromised. Mitigated by per-vendor scope limitation and customer-data minimization at every layer.
Contact

security@mails.ai for security issues only. For everything else, support@mails.ai.

Closed beta

Built for agents.
Self-serve at every volume.

Public API opens Q3 2026. Drop ~6 lines into your agent and ship.

npmpnpmbunpip
$ npm install @mailsai/sdk
Packages publish with cohort 1 · Q3 2026