HHQ FS
All your wealth · one ledger · liveSign inStart free
Security policy

Coordinated Vulnerability Disclosure Policy

HQ FS welcomes good-faith security research on every property under hq-fs.com. This policy describes what is in scope, what is out of scope, how to report a vulnerability, and what to expect from us in return. It is the canonical source referenced from the Policy: field of every /.well-known/security.txt file we publish.

Last reviewed
2026-07-17
Version
1.1
Disclosure
security@hq-fs.com

1. In brief

HQ FS operates a coordinated vulnerability disclosure programme covering every property under hq-fs.com. The full policy below is the binding text; this section is for orientation.

  • What we want. Good-faith security research on the surfaces listed in section 2 — authentication, portfolio data access, the agent API, the marketing site, and the staff-only administration surface.
  • How to report. Email security@hq-fs.com, encrypting sensitive proof-of-concept payloads with our published PGP key — notthe in-product "Report a problem" widget. See section 4.
  • What you get from us. Acknowledgement within 3 business days, preliminary triage within 10 business days, and a remediation target of 30 days for Critical and High issues — under the safe harbour in section 3.
  • Disclosure window. 90 days, coordinated, starting from acknowledgement. See section 5.

2. Scope

In scope (any subdomain of hq-fs.com and the production domains for each HQ FS application):

  • Authentication and session management on the auth server.
  • Portfolio data access, transaction integrity, and privilege boundaries on the Ledger application.
  • Agent API surface and workspace isolation on the Docs application.
  • Public marketing surface on Home.
  • Administration and tenant-management surface on Admin (note: Admin is staff-only; report exposure of authenticated views, not the views themselves).

Out of scope:

  • Denial-of-service, volumetric, or rate-exhaustion testing.
  • Social engineering of HQ FS staff or contractors.
  • Physical attacks against any office or data centre.
  • Vulnerabilities in third-party services we depend on (Stripe, Resend, Cloudflare, etc.) — please report those to the upstream vendor.
  • Findings that require already-compromised end-user devices, browser extensions, or browser zero-days.
  • Reports generated solely from automated scanners with no demonstrated impact.
  • Vulnerability reports submitted through the in-product "Report a problem" diagnostic widget instead of the channel in section 4. That widget is for product bugs; its recordings may contain sensitive data and it does not reach the security team.

3. Safe harbour

We will not pursue civil, administrative, or law-enforcement action against researchers who:

  • act in good faith,
  • avoid privacy violations, data destruction, and service disruption,
  • provide us a reasonable opportunity to remediate before disclosure,
  • and stay within the scope above.

If you are uncertain whether a particular activity is permitted, ask first at security@hq-fs.com.

4. How to report

Email security@hq-fs.com. Encrypt sensitive proof-of-concept payloads with the PGP key published at /.well-known/atlas-labs-pgp.asc.

Do not use the in-product "Report a problem" widget to report a security vulnerability. That feature records a diagnostic session (network requests and responses, console output, errors, navigation) to help us fix ordinary product bugs, and it is routed to product support rather than to the security team. A recording of an exploit is the wrong place for a vulnerability: the session may capture sensitive data — including data belonging to other users or to you — and a proof-of-concept should not be committed to a diagnostic report. Please email security@hq-fs.com as above instead. For what the widget does and does not capture, see the Privacy Notice, section 3.5.

A useful report includes:

  1. A clear description of the vulnerability and its impact.
  2. Reproduction steps (URLs, parameters, sample requests).
  3. Any proof-of-concept code or screenshots.
  4. Your preferred attribution name (or anonymous, if you prefer).

We will acknowledge receipt within 3 business days, provide a preliminary triage assessment within 10 business days, and aim to remediate Critical or High issues within 30 days. Medium and Low issues are scheduled into the regular release cadence.

5. Coordinated disclosure

We follow a 90-day coordinated disclosure window starting from the date of acknowledgement. Public disclosure before the window expires is permitted only if HQ FS has confirmed the issue is fixed in production.

If a fix is not feasible within 90 days, we will agree an extension with the reporter in writing. We do not invoke extensions to avoid disclosure.

6. Recognition

Researchers who report valid issues are credited (with their consent) in our public Hall of Fame at /security/hall-of-fame and earn the security_researcher Legendary achievement on their Atlas account.

A formal monetary bounty programme is on the UA Audit's medium-term roadmap (Section 9.2 — Phase 2 private programme). Until that programme is funded, recognition is non-cash; this policy is not a contract for payment.

7. Contact

security@hq-fs.com · PGP fingerprint published at /.well-known/atlas-labs-pgp.asc.

For the customer-facing security narrative — how we protect your data — see the Security overview. For the legal contract framing the service, see the Terms of Service; for how we handle personal data, the Privacy Notice.

End of policy · version 1.1 · 2026-07-17· canonical for every HQ FS domain's /.well-known/security.txt