Security & disclosure
Security and vulnerability disclosure
How to report a problem in this platform, what we promise in return, and what we have not done yet.
Last reviewed 31 August 2026
Report a security issue to us and we will not pursue legal action against you for good-faith research conducted under this policy.
Safe harbour
- We will not initiate or support legal action against you for accessing, testing or disclosing a vulnerability in good faith under this policy.
- We will not report you to law enforcement for good-faith research under this policy.
- If a third party brings action against you for research conducted under this policy, we will make it known that your activity was authorized.
- You are authorized to test the systems listed in scope below, subject to the rules.
In scope
- cainstudio.online and its subdomains
- mcpgate.online and its subdomains
- The published API surface of either site
- The self-hosted MCPGate distribution
Out of scope
Not because these are uninteresting, but because we cannot authorize you to do them — several would harm other people’s service or someone else’s systems.
- Denial of service, volumetric testing, or anything that degrades availability for other users -- we cannot authorize you to break the service for someone else.
- Social engineering of our people, customers or suppliers.
- Physical attacks, and attacks against our suppliers' infrastructure (Stripe, the hosting provider, the registrar) -- report those to them.
- Automated scanner output with no demonstrated impact.
- Missing hardening headers or best-practice findings with no exploitable consequence, unless you can chain them into one.
Rules we ask you to follow
- Use only accounts you own, or test data you created.
- Stop as soon as you have demonstrated the issue -- do not pivot, persist, or exfiltrate more than the minimum needed to prove impact.
- If you encounter another customer's data, stop immediately and tell us. Do not save it.
- Give us a reasonable opportunity to fix the issue before disclosing it publicly. We suggest 90 days and will usually be much faster.
What you can expect from us
| Stage | Target |
|---|---|
| Acknowledgement of your report | 3 business days |
| Initial assessment and severity triage | 10 business days |
| Status update cadence until resolution | every 10 business days |
| Public advisory after a fix ships | within 30 days, credited if you wish |
We do not currently run a paid bug bounty. We say so rather than implying one: if a reward matters to you, decide before you spend the time. We do credit reporters in the public advisory, by name or handle, if they want it.
Report a vulnerability
Two channels. Email reaches us at security@cainstudio.online. The form below posts directly to our own API and returns a reference id, which exists because a disclosure channel that silently loses reports is worse than none — a researcher who cannot reach you publishes instead.
Threat model
We publish the threat model rather than summarising it: the trust boundaries, the adversaries we model, what each control does and does not stop, and the residual risk we accept. It names the attacks we do not currently defend against, which is the part worth reading.
Read the threat model → · Trust center · security.txt
How this platform is built
Relevant to anyone assessing us, stated without embellishment: the decision path fails closed and never converts an unknown verdict into an allow; tenant isolation is enforced at the boundary and every fabric store is tenant-scoped; API keys are stored as SHA-256 fingerprints, never in the clear; evidence records are signed so alteration is detectable; and the site runs a nonce-based Content-Security-Policy with no unsafe-inline for scripts. None of this has been reviewed by anyone outside the team — see what we don’t do yet.