Found a vulnerability? Tell us first.

• Report to: security@trustreply.app
• Acknowledgment SLA: Within 3 business days.
• Triage SLA: Within 7 business days.
• Safe harbor: Yes — for testing that follows this policy.
• Bug bounty: Not yet. We credit publicly and send merch.
• Coordinated disclosure: 90 days, extendable by mutual agreement.

Email security@trustreply.app. Please include:

• A description of the vulnerability and its potential impact.
• Steps to reproduce, including any proof-of-concept code, requests, or screenshots.
• The affected URL, IP, or endpoint.
• Your name and how you'd like to be credited (or that you'd prefer to remain anonymous).

If your report contains sensitive material, request our PGP key in your initial email and we'll send it. [Placeholder: replace with a published PGP key fingerprint once generated.]

Our security discovery file is at /.well-known/security.txt per RFC 9116.

The following are in scope for this policy:

• trustreply.app and all subdomains we operate, including the marketing site and the web application.
• TrustReply's public APIs.
• TrustReply mobile clients, if and when we publish them.

Examples of in-scope issues include (but are not limited to):

• Authentication and session bypass
• Authorization flaws (IDOR, tenant boundary violations)
• Server-side and client-side injection (SQLi, XSS, SSRF, etc.)
• Sensitive data exposure
• Remote code execution
• Account takeover
• Cryptographic flaws affecting Customer Content
• Privilege escalation
• Prompt-injection or jailbreak techniques that result in exfiltration of another tenant's data or unauthorized actions on a customer's behalf

The following are not in scope. Reports limited to these issues won't be considered eligible for credit:

• Findings on third-party services we don't operate (e.g., Supabase, Vercel, Anthropic, Resend, Stripe). Report those to the relevant vendor.
• Best-practice or hardening suggestions without a demonstrable security impact (e.g., missing security headers without an exploit path).
• Denial of service via volumetric attacks, rate-limit testing, or brute force.
• Self-XSS, clickjacking on pages without sensitive actions, missing autocomplete attributes, or missing cookie flags on non-sensitive cookies.
• Social engineering of TrustReply staff, customers, or vendors.
• Physical attacks on TrustReply offices, devices, or staff.
• Findings from automated scanners without manual validation.
• Reports about software versions without a demonstrated exploit path on TrustReply.
• Outdated browsers or operating systems beyond support.
• Issues that require the user to install malicious software or grant excessive permissions.

We will not pursue legal action against you for security research conducted in good faith and consistent with this policy. Specifically, if your activity is consistent with this policy, we consider it:

• Authorized in accordance with the Computer Fraud and Abuse Act (CFAA) (and equivalent state laws);
• Authorized in accordance with the Digital Millennium Copyright Act (DMCA) for circumvention of technical measures used to protect the systems in scope;
• Exempt from restrictions in our Terms of Service that would interfere with conducting security research, and we waive those restrictions on a limited basis for the purpose of this policy.

You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this policy, we will make it known that your actions were conducted in compliance with this policy.

If at any time you have concerns or are uncertain whether your research is consistent with this policy, please contact us at security@trustreply.app before proceeding.

• Make a good-faith effort to avoid privacy violations, degradation of service, and destruction of data.
• Use only accounts you own or have explicit permission from the account holder to test. Do not access another customer's data.
• If you encounter Customer Content during testing, stop, do not download or further access it, and report it immediately.
• Do not run automated scanners against production at a rate that affects service performance.
• Do not publicly disclose the vulnerability before a fix has shipped and we've agreed on a disclosure timeline (see Section 9).
• Do not engage in extortion, threats, or demands for compensation as a condition of disclosure.

• Acknowledge your report within 3 business days.
• Triage and respond with an initial severity assessment within 7 business days.
• Communicate openly about progress and expected fix timelines.
• Fix critical issues as quickly as practical — typically within 30 days for high-severity issues affecting Customer Content.
• Credit you publicly (if you want) once the fix is shipped.
• Not pursue legal action against you when your research follows this policy.

TrustReply is solo-built and bootstrapped. We don't run a paid bug-bounty program today. We do this instead:

• Hall of fame. With your permission, your name (or handle) on a public security acknowledgments page.
• Merch. A TrustReply security-researcher T-shirt for valid, in-scope reports.
• Direct response. The founder (Wil) reads every security report personally.

If we launch a paid bounty program in the future, valid reports submitted before then will be retroactively eligible according to the program's rules at the time.

We follow coordinated disclosure principles:

• Default disclosure window is 90 days from initial report, extendable by mutual agreement if a fix is complex or affects upstream dependencies.
• For critical issues actively being exploited, we'll work toward a shorter timeline.
• We'll coordinate the disclosure timing with you so we can ship a fix and customers can update before details become public.
• If a fix requires customer action (rare), we'll communicate it before disclosing externally.

Report vulnerabilities to security@trustreply.app.

For questions about this policy, the same address works. For general security questions, see our Security overview.