Disclosure policy, plainly.
How to report a vulnerability, what is in scope, how we respond. For our broader security posture, see /trust.
Ask an assistant to explain it
Get a short, plain-language summary of this page.
What this policy covers
This is our disclosure policy. It covers what to report and how. Good-faith research is always welcome. We won’t take legal action against researchers who follow this scope.
How to report
Email support@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-score manipulation that lets a sender gain unwarranted trust 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 (Cloudflare, Vercel, Neon, OpenAI, Stripe or any other vendor on our sub-processors list) 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
- We read every report — we do not commit to a reply, and we fix what turns out to be real.
- 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, and no payment for reports.
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, every row keyed to its workspace.
- 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
support@mails.ai for security issues and for everything else.
What to read next.
Our wider security posture is on the Trust page. The vendors that handle data are on the sub-processors list, and how we handle your data is in the privacy policy.