Grail Atlas — Responsible Disclosure Policy

DRAFT:this policy is in working-draft form pending review by qualified counsel. The content is the Grail Atlas team's best-effort framework; treat it as informational until the watermark is removed.

DRAFT. Counsel-review pending. Once approved, this becomes the permanent home of the disclosure policy and is linked from /.well-known/security.txt.

Last updated: 2026-05-19 (draft)

Our promise

If you find a security vulnerability in Grail Atlas, please tell us. We will:

• Acknowledge your report within 72 hours.
• Provide a remediation timeline within 7 days.
• Keep you updated on progress at a cadence we agree on.
• Credit you publicly (with your consent) once the issue is resolved.
• Not pursue legal action against good-faith research that follows this

policy.

Scope

In scope:

• The grailatlas.com web application (Next.js front-end, API routes).
• The Grail Atlas Supabase project (sgzrlnnkuvyypsbvfbwf.supabase.co),

but only in ways that don't compromise other users' data.

• The GitHub repository and CI/CD pipeline.

Out of scope:

• Social-engineering attacks against Grail Atlas staff, contractors, or

users.

• Denial-of-service testing against production.
• Physical attacks against Grail Atlas property.
• Issues in third-party services (Supabase, Vercel, GitHub) — report

directly to them.

Safe-harbor terms

Research that follows this policy is authorized under our terms. Specifically:

• You may probe the application using standard security tools.
• You may create test accounts (but please use realistic, throwaway data —

no real PII other than your own).

• You may NOT access, modify, exfiltrate, or destroy data belonging to

other users.

• You may NOT publicly disclose the vulnerability until we have agreed on

a release date — typically 90 days after report.

What to report

We are particularly interested in:

• Authentication or session-management flaws.
• Authorization / RLS bypass — getting at another user's portfolio,

saved searches, owner reports, or seller-dossier data.

• Server-side code injection (SQL, OS command, template).
• SSRF against internal endpoints or cloud metadata.
• Stored XSS in any UGC surface (signals, owner reports, comments).
• Sensitive data exposure (logs, error messages, browser storage).
• Defects in the score-audit-trail integrity (canonical-JSON hash

collisions, replayable input forgery).

What's NOT a vulnerability for our purposes

• Missing security headers on legacy paths that don't accept user input.
• Self-XSS or vulnerabilities requiring physical access to a user's device.
• Click-jacking on pages without authenticated actions (we enforce

frame-ancestors 'none' regardless).

• Username enumeration via timing — we run constant-time comparisons

on every auth path; documented timing differences below 10ms are considered noise.

• Issues that only affect outdated browsers (>2 years old).

How to report

Email security@grailatlas.com. Include:

• A clear description of the vulnerability.
• A proof-of-concept (the smallest one that demonstrates the issue).
• Your assessment of the impact.
• Your name (if you'd like credit) and how to reach you.

If you'd like to use PGP, we'll publish a key once the program graduates out of draft. In the meantime, we accept reports over plain email and follow up over a channel you choose.

Hall of fame

The first ten researchers who report a valid, fixable vulnerability are listed here once the issue is closed (with consent). We don't currently run a paid bounty — we plan to graduate to one after the first 25,000 monthly visitors.

[Counsel to validate safe-harbor wording per jurisdiction.]