Vulnerability Disclosure Policy

1. How to report

Send your report to hello@quantumpipes.com with the subject line Security: ASKQP <short description>.

Please include:

• A description of the vulnerability and the component affected.
• The URL, endpoint, repository, binary, or component where you observed it.
• Steps to reproduce, including any payloads, screenshots, or scripts. Text-based proofs are preferred over screen recordings.
• The version of the AskQP desktop application if applicable (Settings → About).
• The impact you believe the vulnerability has.
• Your name or handle and how you would like to be credited if we publish a fix advisory.

If you cannot reach us by email, see Section 2 for alternative encrypted reporting channels.

2. Encrypted channels

For sensitive reports we offer the following encrypted-by-default channels. Pick whichever fits your workflow.

• GitHub Security Advisory (recommended). Open a private advisory in the affected repository under github.com/quantumpipes. Reports are end-to-end encrypted in transit and at rest by GitHub, scoped to project maintainers, and link cleanly to a CVE on resolution. This is the channel we direct most researchers to.
• OpenPGP / PGP. A team OpenPGP key for hello@quantumpipes.com is available on request. Email us with the subject line "Security: PGP request" and we will return our current public key, fingerprint, and verification instructions before you send the report. We rotate the key on a published schedule and pre-share the next key during each transition window.
• Signed mail. If your client supports it, you may S/MIME-sign your initial email so we can verify the sender on first contact.

Do not send sensitive proof-of-concept material in plaintext if you have a reasonable alternative. If none of the above are workable for you, send a redacted summary by email and we will coordinate a secure handoff before you share the full payload.

3. Scope

In scope:

• The marketing site: www.askqp.com and askqp.com.
• The askqp.com authentication Worker (api.askqp.com or equivalent), including magic-link issuance and verification, session-cookie handling, and account migration.
• The Stripe webhook Worker (stripe-webhook.askqp.com or equivalent), including checkout-session creation, license issuance, and license-signature verification.
• The AskQP desktop application binary (Tauri shell + Python sidecar), including the loopback-only sidecar's HTTP API and its Bearer-token gating.
• The AskQP cloud-action endpoint and the inference-routing layer.
• The Capsule chain protocol: signature integrity, hash-chain verification, and replay resistance for capsules sealed by the application.
• Public source code published under github.com/quantumpipes.
• Public well-known endpoints (/.well-known/security.txt, robots.txt, sitemap.xml, llms.txt).

Out of scope: see Section 11 for a complete list, including customer-deployed instances of the platform, third-party services, and findings we typically consider low priority.

4. Rules of engagement

To remain within the safe harbor in Section 6, please:

• Test only against assets in scope (Section 3).
• Use only your own accounts. Do not access, modify, or store data that does not belong to you. If you accidentally see another customer's data, stop, do not save copies, and tell us.
• Stop the moment you confirm a vulnerability. Do not enumerate further customers, accounts, or records.
• Do not run aggressive automated scanners against production. A handful of confirmed requests is enough to demonstrate impact. Cap your test rate at 10 requests per second per endpoint unless we agree otherwise in writing.
• Do not perform any action that would degrade availability for other users (denial of service, brute force, mass scraping).
• Do not exfiltrate data beyond the minimum needed to demonstrate the issue. Delete any data you incidentally access and confirm deletion in your report.
• Do not attempt to phish, social-engineer, or impersonate any Quantum Pipes member, employee, contractor, or customer.
• For payment-related testing, use Stripe's test cards only. Never submit a real payment instrument as part of a security test.
• For desktop-binary research, you may install AskQP on hardware you control; do not redistribute the binary, modify it for redistribution, or attempt to disable or strip license verification for use, sharing, or commercial purposes (those actions are governed by the Acceptable Use Policy).
• Keep the report private until we have shipped a fix or until ninety (90) days have passed since acknowledgment, whichever is earlier. We will work with you on coordinated public disclosure under Section 7.

5. SLA and what to expect

What you can expect from us, on a clock:

If we miss a target, we will tell you why and propose a new one. If you disagree with our severity assessment, raise it in your point-of-contact thread; we will reconsider in good faith.

6. Safe harbor

If you make a good-faith effort to comply with this policy:

• We will not pursue or support a civil claim, criminal referral, or law-enforcement action against you for security research on in-scope assets.
• We consider your activity to be authorized for purposes of: the U.S. Computer Fraud and Abuse Act (18 U.S.C. § 1030); the anti-circumvention provisions of the U.S. Digital Millennium Copyright Act (17 U.S.C. § 1201); state computer-misuse, unauthorized-access, and trespass-to-chattels statutes; analogous foreign laws (including the U.K. Computer Misuse Act 1990 and the EU Directive 2013/40/EU as transposed in your member state); and our website Terms of Service and Acceptable Use Policy.
• We will work with you to clarify and resolve any inadvertent overstep. A genuine accidental overstep, reported promptly and not exploited further, will not cost you the safe harbor.

If you are uncertain whether a planned action is in scope, ask first at hello@quantumpipes.com with the subject line "Security: scope question." We would much rather answer a "can I?" than navigate a misunderstanding after the fact.

This safe harbor does not extend to: research targeting third parties, our customers, our contractors, or our employees; actions that violate this policy or the AUP; actions prohibited by law where we lack authority to authorize them; or exfiltration, retention, or sale of customer data. Our authorization is limited to the systems we control.

7. Public disclosure and credit

We support coordinated disclosure. After a fix ships we are happy to:

• Co-author a public advisory or write-up.
• Add your name (or chosen pseudonym) to the project security advisory, the changelog, and any CVE assigned. With your permission we will list you on the Acknowledgments section of /.well-known/security.txt and a public credits page on askqp.com.
• Link to your own write-up.
• Coordinate timing with your conference talk if you intend to present the finding.

If a fix requires more than ninety (90) days for legitimate engineering reasons (for example, a protocol change requiring a coordinated client and server upgrade), we will tell you why and ask for an extension. We will never ask for an extension to bury a finding.

8. AI-system reports

AskQP is an AI product, so a few categories of report deserve specific guidance:

• Prompt injection and jailbreak. Findings against the cloud-action service or against shipped guardrails are in scope. Include the input, the model or component, and the policy or guardrail you bypassed. Coordinated jailbreaking campaigns are not in scope and are governed by the AUP; one-off proof-of-concept reports are welcome.
• Capsule, signature, and audit-trail integrity. Findings such as forgery, replay, hash-chain breakage, signature downgrade, post-quantum-scheme misuse, or verification bypass are high priority. Please include enough detail for us to reproduce against published test vectors.
• Cross-tenant or cross-customer leakage. Any cloud-action behavior that surfaces another customer's prompt, context, output, or telemetry on your endpoint is a critical finding.
• Training-data exfiltration via outputs. Demonstrations that the cloud-action service emits identifiable third-party copyrighted material in response to plausibly unrelated prompts are in scope.
• Model-output harms. Toxicity, bias, and hallucination severity are not vulnerabilities under this policy. We welcome those reports separately at wecare@quantumpipes.com; they will not receive the disclosure-policy SLA above.

9. Payments and licensing

AskQP processes payments through Stripe and issues Ed25519-signed licenses on successful checkout. Reports in this area should follow these specific rules:

• Use Stripe test cards only. A list of test numbers is published at stripe.com/docs/testing. Do not submit a real payment instrument as part of any test.
• Do not probe Stripe directly. Stripe runs its own program at stripe.com/security. If a finding implicates Stripe's infrastructure rather than our integration, we will help you route it.
• License-signature attacks are in scope. Forging, downgrading, replaying, or extending an Ed25519-signed AskQP license is a critical finding. Include the public key you observed, the signed payload, and the verification step that accepted it.
• Webhook-replay or signature-bypass against stripe-webhook.askqp.com is in scope.
• License modification for personal study is permitted as security research; redistribution, evasion of license caps, or commercial use of a forged license is governed by the AUP and is out of safe-harbor scope.

10. Desktop binary and sidecar

The AskQP desktop application is a Tauri shell hosting a Python sidecar bound to the loopback interface only. Reports about the application are in scope when they relate to:

• Network bindings other than loopback, or any path by which the sidecar can be reached from a non-loopback origin.
• Bypasses of the Bearer-token gating between the Tauri shell and the sidecar, or any path that allows an unauthenticated request to reach a sidecar endpoint.
• Tauri capability misconfiguration that grants more privilege than the published manifest.
• CSP bypass, Tauri IPC abuse, or any path by which a web-content origin reaches host capabilities not granted in the capability manifest.
• Sidecar middleware bypass: authentication, authorization, rate limiting, audit logging.
• Application-update integrity findings: signature checks on updates, channel selection, downgrade attacks.
• Local-file disclosure or arbitrary file write through the Vault ingestion path or any other application-controlled file operation.

You may decompile or reverse-engineer the desktop binary as part of good-faith research on hardware you control. Do not redistribute the binary, modify it for sale or sharing, strip license verification, or publish a tool whose primary purpose is to defeat license enforcement; those activities fall under the AUP, not this policy.

11. Out of scope

The following are out of scope or low priority:

• Customer-deployed enterprise instances. Self-hosted or air-gapped deployments are owned by the deploying organization. Please report to them directly. We will help relay if you cannot identify a contact.
• Private repositories, internal services, or infrastructure we have not made publicly accessible.
• Findings that depend on social engineering, physical access, or stolen credentials.
• Reports that consist only of automated scanner output without a demonstrated security impact.
• Issues in third-party services we link to or depend on.
• Missing security headers without a demonstrated exploit. We operate a hardened header set; report deviations only when you can show an impact.
• Self-XSS, clickjacking on pages with no sensitive state, or login-CSRF on forms that have no authenticated state.
• Email-spoofing concerns for domains we do not send from.
• TLS configuration that already matches modern Mozilla SSL "Intermediate" guidance.
• Reports that require Internet-protocol denial of service (volumetric, SYN flood, etc.) to be exploitable.
• Disclosure of information that is already public.
• User-enumeration findings against the magic-link request endpoint. The endpoint is intentionally enumeration-resistant (always returns 204); reports that exploit timing or other side channels with realistic precision are in scope.

12. Recognition and bounty

We do not currently operate a paid bug bounty. We do extend recognition that researchers value:

• Public credit (with your permission) on the project security advisory, the CVE record, the changelog, and a credits page on askqp.com.
• Acknowledgment in /.well-known/security.txt.
• Quantum Pipes swag where it is meaningful, shipped at our cost.
• A real-human conversation that goes beyond the report. We care about the work, and we want you to know we read it carefully.

If we introduce a paid bounty, we will publish the rules here and announce it on the marketing site. The safe harbor in Section 6 will continue to apply regardless of whether a bounty is in effect.

13. Changes

We may update this policy as our security program matures. The "Last updated" date at the top reflects the most recent material change. We will not retroactively narrow safe-harbor coverage for research already submitted in good faith under a prior version.

14. Contact

• Primary contact: hello@quantumpipes.com (subject line "Security: ASKQP <short description>")
• security.txt: www.askqp.com/.well-known/security.txt
• GitHub Security Advisories: github.com/quantumpipes
• Postal: Quantum Pipes Technologies LLC, 30 N Gould St, Ste N, Sheridan, WY 82801, USA
• Languages: English

Thank you for spending time on this. The work matters.