// Trust Center

Security Contact & CVD Policy

How to responsibly report a security vulnerability in AuthorityRail's execution authority infrastructure. Safe-harbor language for good-faith researchers. 90-day disclosure window doctrine.

Last revised: 2026-05-17 · Version v1.0

Primary security contact

[email protected]

PGP key

/pgp-key.txt (founder-generation pending; encrypted transit via TLS + Signal exchange in the interim)

Response SLA

Within 24 hours, business days; 48 hours weekends

Acknowledgement

Within 5 business days

Triage decision

Within 10 business days

Researcher hall of fame

authorityrail.com/trust/researcher-hall-of-fame (populated upon first acknowledged report)

Coordinated Vulnerability Disclosure (CVD) policy

AuthorityRail subscribes to the AuthorityRail Standards Foundation Coordinated Vulnerability Disclosure doctrine:

90-day disclosure window by default, from acknowledged report to public advisory.
Shorter window if the vulnerability is actively exploited or if a public disclosure has already occurred.
Longer window by mutual agreement with the researcher when the remediation is complex (rare).
Public advisory published at trust.authorityrail.com/security-advisories/<YYYY-MM-DD>-<CVE-or-ID>.md at the disclosure deadline.

What to report

Authentication or authorization bypass on any AuthorityRail surface (gate, customer-api, verify, internal-ops).
CAR signing chain integrity issues (forged CARs, signature verification bypass, key disclosure).
Multi-tenant isolation breaks (one tenant reading another tenant's data).
Stored or reflected XSS, SSRF, SQLi, RCE in any AuthorityRail-controlled surface.
Subdomain takeovers, dangling DNS records, leaked credentials in public repositories.
Sensitive data exposure in API responses, error pages, logs.
Cryptographic weaknesses in the AuthorityRail-controlled signing path.

What is out of scope

Sub-processor issues (Cloudflare, Railway, Supabase, Stripe, etc.) — please report to the sub-processor directly per their CVD policies.
Self-XSS, social engineering, physical attacks.
Issues requiring already-compromised credentials.
Outdated browser warnings, missing CSP headers on static asset hosts (unless they enable a separate vulnerability).
Volumetric DoS / DDoS — Cloudflare's perimeter is the defense layer for these.

Safe harbor

AuthorityRail will not pursue legal action against good-faith security researchers who:

Make a good-faith effort to avoid privacy violations, destruction of data, and interruption or degradation of AuthorityRail services.
Only interact with their own AuthorityRail accounts (or AuthorityRail-provided test accounts).
Report findings privately to [email protected] before any public disclosure.
Refrain from accessing or exfiltrating customer data beyond the minimum required to demonstrate the vulnerability.

If you believe your research is at risk of crossing these lines, contact [email protected] first to coordinate.

What to include in the report

Steps to reproduce.
Affected component (gate, customer-api, verify, internal-ops, billing, status, homepage, standards).
Expected behavior vs observed behavior.
Estimated impact and severity per the AuthorityRail SEV ladder if known (SEV ladder).
Your preferred attribution name and channel for the researcher hall of fame.

What we will not do

Pay bounties at this stage (a public bug bounty program is deferred to a later sprint; in-scope reports are acknowledged via the researcher hall of fame and direct outreach).
Disclose researcher identity without explicit consent.
Argue with researchers about severity classification — your assessment is treated seriously even if ours differs.