Responsible Disclosure

1. How to report

Email [email protected]. One report per issue. Please include enough for us to reproduce it without guessing:

• The affected URL, endpoint or asset.
• A clear description of the issue and its impact.
• Steps to reproduce, and a proof of concept if you have one.
• Any request or response logs, screenshots or recordings that help.
• How you would like to be credited, if at all.

If the finding is sensitive, say so in your first message and we will move the conversation to an encrypted channel before you share details.

2. What to expect from us

3. Safe harbour

If you make a good-faith effort to follow this policy, we will not pursue or support legal action against you, and we will treat your research as authorised under applicable computer misuse and anti-circumvention laws. If a third party brings action against you for work that complied with this policy, we will make that authorisation clear.

Good faith means: you stopped as soon as you confirmed the issue, you did not access or retain data belonging to anyone else, and you gave us a reasonable chance to fix it before telling anyone.

4. Scope

In scope

• boltkey.io and its subdomains.
• The access request form and the systems that receive it.
• Our email sending and authentication configuration, including SPF, DKIM and DMARC.
• Publicly reachable infrastructure we operate, and credentials or secrets of ours that you find exposed.

Out of scope

• The private beta product, unless you are an enrolled participant testing your own tenant.
• Third-party services we merely use, where the issue belongs to the vendor.
• Reports generated solely by automated scanners with no demonstrated impact.
• Missing hardening headers, cookie flags, TLS configuration preferences or version disclosure without a working exploit.
• Rate limiting on the signup form absent a demonstrated abuse path, and email enumeration on a public waitlist.
• Social engineering of our staff or customers, physical attacks, and denial of service or volumetric testing.
• Self-XSS, clickjacking on pages with no sensitive action, and issues requiring a rooted device or fully compromised browser.

5. Rules of engagement

• Use your own test data and your own accounts. Never touch another person's.
• If you encounter personal data, stop, do not save it, and tell us immediately.
• Do not degrade our service. No load testing, no spam, no destructive payloads.
• Do not modify or delete anything, and do not maintain persistence.
• Do not publish before we have agreed timing with you.

6. Rewards

We do not run a paid bounty programme yet. We do publish a security acknowledgements list, we will credit you by name or handle as you prefer, and reporters who help us before launch get standing early access to the product. When a formal bounty opens, everyone who reported in this period will be told first.

7. Why we take this seriously

We are building a security product. A company in our position that handles disclosure badly has already answered the most important question a customer could ask about it. So we would rather hear it from you than from anyone else.