Security Disclosure Policy

1. Reporting channels

You can reach the Beelab security inbox in two ways. Either works, the first is preferred because it routes only to security work.

• Primary: [email protected]. Use this for any finding that may affect users of the marketing site, the install, the AI gateway, the AI mesh, the public tunnel, the booking flow, or the assistant widget.
• Secondary: [email protected]. Use this when you are not sure whether a finding is in scope; you will still get a human reply.

Both addresses are listed in /.well-known/security.txt per RFC 9116. When you write, include a clear reproduction (steps, URL, payload, expected vs observed behavior), the time you observed the issue, and any logs or screenshots that help.

2. Scope

Anything served from beelab.sh and any subdomain of beelab.sh is in scope. This includes the marketing site, the assistant widget API, the booking and contact endpoints, public status pages when wired, and any documentation or API surface published under the same apex domain.

• Authentication flows, session handling, CSRF, mass-assignment, input validation issues, and authorization gaps on any endpoint.
• Server-side request forgery, SQL injection, remote code execution, deserialization issues, command injection, path traversal.
• Client-side issues with real impact: stored XSS, DOM clobbering that leads to credential theft, CSP bypasses that enable XSS.
• Information disclosure through misconfigured caching, public objects that should be private, or leaked tokens in HTTP responses or error pages.
• Supply-chain issues you can demonstrate against a Beelab-owned package, image, or build artifact.

3. Out of scope

The following classes of report are not eligible. If you are not sure, send the report anyway and mark it “possibly out of scope” in the subject. You will still get a reply.

• Findings against third-party services we use as sub-processors or vendors. Report those to the vendor; we will help you make contact if you are stuck.
• Social engineering attempts against staff, partners, customers, or anyone you found through Beelab. This includes phishing, phone calls, in-person approaches, or hiring funnel abuse.
• Physical attacks against any Beelab office, device, or hardware shipped to a customer. Hardware security against an attacker with physical possession is not in scope for this program.
• Volumetric denial-of-service, brute-force on public forms beyond standard rate-limit thresholds, or any test that degrades the service for other users. Test on your own copy.
• Reports based on missing security headers, weak ciphers, or scanner output without a working exploit chain. Show the impact.

4. Safe harbor

Good-faith security research on the scope above will not be pursued legally or referred to law enforcement. You qualify if you stop the moment you confirm the issue, do not access or download more user data than is needed to demonstrate the vulnerability, do not modify or destroy data that is not yours, and report promptly through one of the channels above.

The Computer Fraud and Abuse Act in the United States, the Computer Misuse Act in the United Kingdom, and analogous statutes in your jurisdiction may apply to access without authorization. This policy is your written authorization for in-scope testing that follows the rules above.

If a third-party tool, service, or law you must follow conflicts with this policy, contact us first and we will work it out.

5. Disclosure timeline

• Within 72 hours, you receive a human acknowledgement from [email protected] with a tracking reference.
• Within 14 days, you receive a triage outcome: either a clear plan with a target fix window, or an explanation of why the report is not actionable.
• Within 90 days,the issue is either fixed, mitigated with an explicit compensating control, or publicly disclosed with both parties' agreement. You can request a shorter timeline for active-exploit cases; we will match it.
• If we go past 90 days without progress, you may publish your finding after a single written notice. We prefer coordinated disclosure; we will not retaliate if you do not get it.

6. Acknowledgments

With your permission we list reporters who help us in a public security hall of fame. You choose the name we use (your real name, a handle, or anonymous). The list will be populated as reports arrive; the first cohort of acknowledgments will land here once the first eligible report is fixed.

7. Preferred encryption

A PGP fingerprint for [email protected] is in rotation. To get the current public key, email [email protected]with the subject “PGP key request” and we will reply with the fingerprint and the ASCII-armored block. The key will also be published here once the rotation is final.

If your report contains exploit code or any data we should not see in plain text, encrypt it. If you cannot encrypt, write us first and we will set up a secure channel.