Security & Disclosure
Tell us what you found. We will not come after you for it.
This is our vulnerability disclosure policy, in plain language: what is in scope, the safe-harbour commitment we make to researchers, what we can honestly promise on response time, and what we will never do to a report.
Scope
What we want reports on — and what we do not.
In scope
www.theosquantum.com
This marketing and documentation site, including the Knowledge Base and every public tool on it.
AutoPQC product surfaces
Authenticated application surfaces, APIs, and workspaces that Theos Quantum operates directly for the AutoPQC platform.
Out of scope
Volumetric denial-of-service
Load testing, flooding, or any attempt to degrade availability rather than demonstrate a specific flaw.
Social engineering of staff
Phishing, vishing, or pretexting directed at employees, contractors, or their personal accounts.
Physical attacks
Attempts to gain physical access to offices, hardware, or badges. We do not publish addresses to test this against.
Findings requiring a compromised device
Attacks that only work once you already control a victim's browser, endpoint, or account through other means.
Self-XSS
A payload a user would have to paste into their own browser console or address bar to attack themselves is not a vulnerability in our code.
Automated-scanner output without demonstrated impact
A raw scanner report with no proof of concept and no explanation of real-world impact will be closed, not triaged.
Missing headers or best-practice flags with no demonstrated impact
Naming an absent header is not a report. Show the concrete, exploitable consequence of its absence, or we will close it without action.
Third-party services we do not operate
Infrastructure, subprocessors, or vendor products in our supply chain that we do not directly control. Report those to the vendor.
Disagreement with our published methodology
A dispute over the Theos Method's scoring, weights, or tiers is not a security bug — use the methodology-correction path below instead.
What to include
What makes a report actionable.
The faster we can reproduce an issue, the faster it gets fixed. A short list, followed exactly, gets you a faster and more useful reply than a long one that skips these.
In a good report
- The specific URL, endpoint, or product surface affected.
- Steps to reproduce, in enough detail that an engineer can follow them without guessing.
- A proof of concept — a request, script, or short recording — wherever one is possible to provide.
- What the impact actually is: what an attacker gains, and against whom.
- Any preconditions the attack needs, such as a specific role, plan, or account state.
- Whether you want to be credited by name once a fix ships, and how you would like to be named.
What we do with it: log it, attempt to reproduce it against the in-scope surface, assign a severity and an owner, and come back to you — see the internal walkthrough further down this page for the full sequence.
Safe harbour
Act in good faith, within these limits, and we will not pursue legal action.
If you discover and report a security issue in good faith and stay within the conditions below, Theos Quantum will not pursue civil or criminal legal action against you, and we will not report you to law enforcement, for that research.
- Take only the minimum data or access needed to prove the issue — no exfiltration beyond a proof of concept.
- Do not access, modify, or retain data belonging to other customers or to Theos Quantum beyond what your proof requires.
- Do not degrade the availability or integrity of the service for other users while testing.
- Give us a reasonable amount of time to investigate and respond before any public disclosure.
- Stay within the scope defined above.
[PLACEHOLDER: this safe-harbour commitment is pending review by counsel and has not yet been given a formal legal determination]. Until that review completes, treat the paragraph above as our stated intent, not a legal guarantee.
We do not run a paid bug bounty.
There is no monetary reward program today, and we would rather say that plainly than imply one with vague language. What we do offer is acknowledgement and credit — opt-in only — in the acknowledgements below once a fix has shipped.
Response
What we commit to, and what we cannot promise yet.
We will not invent a service-level agreement we have not actually built. The intent below is real; the concrete durations are marked until the company confirms them.
| Stage | What happens | Target |
|---|---|---|
| Acknowledgement | We confirm we received your report and can reproduce or are actively investigating it. | [PLACEHOLDER: target hours — company to confirm] |
| Triage | We assign a severity, tell you whether it is in scope, and give you a point of contact for follow-up questions. | [PLACEHOLDER: target hours/days — company to confirm] |
| Fix or mitigation | We remediate or mitigate the issue, scaled to severity, and let you know once it is resolved. | [PLACEHOLDER: target days — company to confirm, varies by severity] |
Contact
How to reach us.
Report an issue
Email ceo@theosquantum.com with a description and, if possible, a proof of concept.
PGP
Key fingerprint: [PLACEHOLDER: PGP key fingerprint — company to supply]
Public key: [PLACEHOLDER: PGP key URL — company to supply]
Cryptography
How we protect data — and where we have not yet published detail.
We build a product that finds other people's weak cryptography, so we hold ourselves to the same disclosure standard about our own: state exactly what we can substantiate, and mark the rest as a placeholder rather than assert something generic-sounding.
Data in transit
Traffic to this site and to AutoPQC is served over TLS by our hosting platform. The exact TLS version floor, cipher policy, and whether HSTS, a content-security policy, or other hardening headers are enforced are [PLACEHOLDER: TLS/cipher policy and header configuration — infrastructure team to confirm]. We checked this repository directly rather than assume: as of this build, next.config.mjs defines no headers() function, and there is no middleware.ts or vercel.json in the project, so we cannot claim any application-level security headers beyond whatever the hosting platform applies by default.
Data at rest
The specific algorithm, key management approach, and provider for data at rest are [PLACEHOLDER: at-rest encryption algorithm and key management — infrastructure team to confirm]. We would rather leave this open than describe a scheme we have not verified is actually in place.
Our own crypto-agility
AutoPQC exists to help others replace cryptography without a rewrite. Holding ourselves to the same standard is the intent, but intent is not an architecture: the specifics of how our own systems would rotate algorithms are [PLACEHOLDER: internal crypto-agility architecture — engineering to document].
RFC 9116
A machine-readable copy, at the standard location.
The same policy, published as security.txt so scanners and tooling can find it automatically.
# Theos Quantum Technologies Private Limited — security disclosure policy
# See https://www.theosquantum.com/security for the full policy in plain language.
Contact: mailto:ceo@theosquantum.com
Contact: https://www.theosquantum.com/contact
Expires: 2027-07-27T00:00:00.000Z
Preferred-Languages: en
Canonical: https://www.theosquantum.com/.well-known/security.txt
Policy: https://www.theosquantum.com/security
# Encryption: omitted — no public key is published yet. We will add this
# field, with a real key URL, once one exists rather than fake one now.
Served at /.well-known/security.txt.
Hall of thanks
Empty, honestly — no researcher has been credited here yet. Find something first and your name can be the first entry.
Internally
What happens after you click send.
- 1
Intake
A report arrives through a contact channel below and is logged with a unique reference so nothing gets lost in an inbox.
- 2
Reproduce
An engineer attempts to reproduce the issue against the in-scope surface and records the result — reproduced, not reproduced, or needs more detail.
- 3
Severity and ownership
A reproduced issue gets a severity rating and an owner. We come back to you if we need clarification.
- 4
Fix and verify
The owning team ships a fix or mitigation, then verifies it closes the issue you reported before marking it resolved.
- 5
Credit, if you opted in
If you asked to be credited, we add your name to the acknowledgements below once the fix has shipped.
Limits
What we will not do.
- We will not ask you to sign a non-disclosure agreement as a condition of reporting a bug.
- We will not silently patch an issue without crediting a reporter who opted in to be named.
- We do not treat a security report as a sales lead, and no report will be forwarded to sales.
Not a security report
Disagree with a score? That is a methodology correction, not a vulnerability.
A disagreement with how the Theos Method weights a dimension, assigns a tier, or scores a specific asset class is not a security bug — it does not belong in the channels above, and treating it as one would slow down real vulnerability triage.
Send methodology disagreements through /contact marked as a methodology correction. We publish versioned responses rather than silently editing published numbers — read The Theos Method for the current construction and how the method is versioned for how corrections and revisions are tracked over time.
See the rest of our trust posture.
The Assurance Center covers our broader posture, the Attestation Lookup explains our attestation format, and our privacy policy covers data handling.