Where to send it, what is in scope, and a safe-harbour commitment for anyone researching in good faith.
Email security@quorum.dog. Include enough detail to reproduce the issue — a request, a sequence of steps, or a proof of concept. If you would rather not send details by email first, send a short note and we will arrange another channel.
Every report is read by the people who built the system. There is no ticket queue and no triage vendor.
We do not publish a guaranteed response window, because we have not measured one and would rather not invent it. This is a small team. What we will commit to is that reports are read by a person, that you will get a reply, and that we will tell you what we are doing about it.
If you research in good faith and within the scope below, we will not pursue or support legal action against you, and we will treat your report as an authorised contribution rather than an intrusion.
Good faith means: you stopped at the point of proving the issue, you did not access, modify, retain or exfiltrate anyone else’s data, you did not degrade the service for other people, and you gave us a reasonable chance to fix it before publishing.
If you are unsure whether something is in scope, ask before you test. We would rather answer a question than receive an apology.
| In scope | Out of scope |
|---|---|
quorum.dog and its subdomains |
Denial of service, volumetric or resource-exhaustion testing |
The API under /v1/ and the MCP endpoint at /mcp |
Social engineering of our team, customers or vendors |
| Authentication, session handling, and organisation or tenant isolation | Physical attacks, or anything requiring access to a device we control |
| Anything that exposes one customer’s inputs, outputs or receipts to another | Findings in third-party AI providers — report those to the provider |
| Billing, balance, entitlement or spend-cap bypass | Automated scanner output with no demonstrated impact |
Model behaviour is a separate category. A model producing a wrong, biased or objectionable answer is a product issue rather than a vulnerability, and the help page is the right route for it. A prompt that makes the system leak another customer’s data, exceed a spend cap, or act outside its own configuration is a vulnerability, and belongs here.
We will tell you when the issue is fixed. If you intend to publish, we ask for a reasonable window first and will tell you honestly if we need longer and why. We will not ask you to stay quiet indefinitely.
We are happy to credit you by name if you would like that, and equally happy not to.
There is no bug bounty and no payment. We hold no SOC 2 and offer no signed DPA today — the organisations page states the full list of what is and is not in place rather than leaving you to discover it. Saying so here as well, because a researcher deciding where to spend an afternoon deserves to know before they start, not after.
If we become aware of a breach affecting personal data, we notify affected users without undue delay, and within 72 hours of becoming aware where the breach is likely to result in a risk to their rights. Notice goes to the email address on the account. The same commitment is written into the Privacy Policy, which is the binding version.