Our position.
MATRIX welcomes good-faith security research. If you have discovered a vulnerability in any MATRIX-operated system, we want to hear from you — quietly, formally, and without fear of reprisal.
We hold that security research is a public good. A studio that designs intelligence architecture for civilisation cannot treat a researcher who finds a flaw as an adversary. The adversary is the flaw.
If you find a security problem in something we operate, tell us privately first. We will take it seriously, respond quickly, and not pursue legal action against you for reporting in good faith.
How to report.
Security reports should be submitted to the studio's dedicated disclosure channel. Please do not post details publicly until we have had the opportunity to investigate and remediate.
Please do not use public issue trackers, social media, or third-party bug-reporting platforms to disclose a vulnerability in MATRIX systems before we have coordinated a fix. We will always prefer to hear from you first.
For encrypted reports, the current PGP public key for [email protected] is available on request. The fingerprint is published below for verification.
What to include.
A clear report accelerates remediation. Where possible, please include:
- A summary — one or two sentences describing the vulnerability and its potential impact.
- Affected system — the specific hostname, URL, API endpoint, or platform concerned.
- Reproduction steps — a clear, ordered description of how to reproduce the issue, with any prerequisites.
- Proof of concept — where safe to share: a screenshot, request/response pair, or minimal script. Do not exploit beyond what is necessary to demonstrate the issue.
- Impact assessment — what an attacker could achieve: data exposure, privilege escalation, service disruption, or other consequence.
- Your contact details — a name or handle and a preferred channel for follow-up. Anonymous reports are accepted but limit our ability to credit you.
- Disclosure preference — whether you wish to be credited publicly, and if so, under what name.
Our response.
Every report received through the disclosure channel is acknowledged, triaged, and tracked. We commit to the following response timeline.
Scope — what qualifies.
Our disclosure programme covers MATRIX-operated systems. The scope below is deliberately narrow; it is not an invitation to test systems we do not control.
- The studio website matrka.net and its subdomains
- Platforms operated by MATRIX and publicly accessible under studio domains
- Authentication and account systems for MATRIX-operated platforms
- APIs and endpoints published by MATRIX
- Configuration issues affecting confidentiality, integrity, or availability
- Exposed secrets or credentials belonging to MATRIX
- Logic flaws in studio-operated web applications
- Denial-of-service or volumetric attacks
- Social engineering of MATRIX personnel or Clients
- Physical security testing of any premises
- Automated scanning that produces excessive traffic
- Third-party services linked from studio materials
- Client-owned systems operated under a MATRIX engagement (report to the Client)
- Vulnerabilities in discontinued or archived versions no longer in use
- Self-XSS, tabnabbing, or clickjacking without demonstrable impact
- Missing security headers without a demonstrable exploit
- Reports generated solely by automated tools without analysis
Where MATRIX operates a system on behalf of a Client under a separate agreement, security reports concerning that system should be directed to the Client's own disclosure channel. We will coordinate with the Client where a report reaches us directly.
Safe harbour.
MATRIX will not pursue civil action or refer for criminal investigation any researcher who:
We will not initiate legal action or support law enforcement action against researchers who act in good faith under this policy.
We consider a report to be made in good faith when the researcher:
- ◆ Reports promptly and privately Tells us about the issue before disclosing it publicly or to any third party.
- ◆ Does not exploit the issue Limits their activity to what is necessary to demonstrate the vulnerability — no data extraction, no persistence, no lateral movement, no impact on other users.
- ◆ Does not violate privacy Does not access, alter, or destroy data belonging to MATRIX, its Clients, or other users beyond what is strictly necessary to demonstrate the issue.
- ◆ Does not disrupt service Does not degrade or interrupt the availability of MATRIX systems or any Client system.
- ◆ Acts in good faith Does not act with malicious intent, for personal gain, or on behalf of a competitor or hostile party.
Where legal action is taken by a third party against a researcher who complied with this policy in respect of a MATRIX-operated system, MATRIX will make this policy known as evidence of authorisation, to the extent lawful and reasonably practicable.
This safe harbour does not extend to: extortion, ransom, public disclosure prior to coordination, deliberate access to personal data beyond what is necessary for demonstration, or any activity outside the scope described in Section 05.
Recognition & credit.
We credit researchers who report vulnerabilities under this policy, where they wish to be credited.
- ◆ Hall of acknowledgement For confirmed and remediated issues, we maintain an acknowledgement record — a quiet listing of researchers and the nature of their contribution, published at the researcher's discretion.
- ◆ No monetary bounty MATRIX does not currently operate a paid bug bounty programme. We are honest about this. We credit contribution, but we do not pay for reports.
- ◆ Coordination on disclosure We coordinate with the researcher on the timing and content of any public disclosure. We do not publish a report publicly without the researcher's agreement.
- ◆ Anonymous reports Anonymous reports are accepted and treated with the same seriousness. Anonymous researchers cannot be credited publicly.
If we fail.
We hold ourselves to the standard we set. Where we fail to meet it — where a report goes unanswered, a fix is delayed beyond stated timelines, or a researcher is treated poorly — we want to know.
Escalate the matter directly to the Founder: [email protected]. We treat this as a serious failure of the studio, not of the process.
A final word.
We build the conditions under which intelligence can be trusted. That work is only as honest as our willingness to hear when we have failed.
If you have found something, write to us. There is no wrong way to begin a conversation about a flaw, except to keep it to yourself.