Security

Responsible disclosure policy.

We take the security of Meisa and our users' data seriously. If you believe you have found a security vulnerability, please tell us privately so we can fix it before anyone is harmed. This page explains how to report it and what you can expect from us.

Last updated: November 4, 2026

1.How to report

Email [email protected] with "Security report" in the subject line. Please include:

  • what the issue is and where it is (the URL, endpoint, or app and version);
  • the steps to reproduce it, or a short proof of concept;
  • the impact you think it has;
  • a way to reach you if we have questions.

Please do not put other people's personal data in your report. Our contact details are also published in /.well-known/security.txt.

2.What we promise

  • We will reply within 5 business days to confirm we have your report.
  • We will keep you updated while we investigate and fix it, and tell you when it is fixed.
  • If you follow this policy, we will treat your research as authorized, and we will not take legal action against you or ask law enforcement to investigate you because of it. See the "Good-faith security research" section of our Acceptable Use and Anti-Spam Policy.

3.In scope

  • meisa.io and its subdomains that we operate, including the web app and API
  • The Meisa MCP connector

4.Out of scope

  • Services run by third parties that we use, such as payment, sign-in, email, hosting and analytics providers. Please report those to the provider.
  • Denial of service, load testing and stress testing.
  • Social engineering, phishing, and physical attacks against our staff, users, offices or data centers.
  • Reports from automated scanners with no proof of real impact.
  • Missing security headers, cookie flags, or SPF, DKIM or DMARC records, without a working attack that uses them.
  • Clickjacking on pages with no sensitive actions, self-XSS, and CSRF on sign-out or other actions with no impact.
  • Disclosure of software or library version numbers.
  • Issues that need a rooted or jailbroken device, or physical access to a victim's unlocked device.
  • The deliverability or content of emails our customers send through their own AWS accounts.

5.Rules for testing

  • Only test against accounts you own, or accounts whose owner has given you explicit permission.
  • Access only the minimum data needed to show the issue. If you reach data that is not yours, stop, do not copy, keep, change or delete it, and tell us right away.
  • No denial of service, load or stress testing, or anything else that degrades the Service for other people.
  • No social engineering, phishing or spam.
  • Do not run automated scanners against the Service, and do not go beyond a proof of concept: no moving into other systems, no backdoors, no changes to other users' data.
  • Keep the details private. Do not share them publicly or with anyone else until we have fixed the issue or 90 days have passed since your report, whichever comes first. If you need more time or would like to publish sooner, talk to us.

Testing that does not follow these rules is not covered by this policy and is unauthorized access under our Acceptable Use and Anti-Spam Policy.

6.No bug bounty

We do not run a bug bounty program and do not pay for reports. Reporting is voluntary, and we are grateful when you do. Asking for payment as a condition of sharing or keeping quiet about a vulnerability is not covered by this policy.

7.Questions

If you are not sure whether something is in scope or allowed, email [email protected] before you start testing.