Skip to content

// security · disclosure.md

Security & disclosure

How to report a vulnerability in sprintrr, what is in scope, the safe harbor you work under, and what to expect back.

effective
acknowledgement
within 2 business days
rfc 9116
security.txt
on this page

    see also:

    The Trust page covers the broader security program, alongside the Sub-processors list and the Privacy policy. The RFC 9116 machine-readable contact lives at /.well-known/security.txt.

    Reporting a vulnerability

    please don't post publicly:

    Please do not file a public GitHub issue, post on social media, or open a support ticket for security reports — those channels are public and may expose other users.

    Email support@sprintrr.ai with Security report in the subject. The inbox is monitored by the founder/security lead; security-flagged messages are triaged ahead of general support. Include:

    • A description of the issue and its impact.
    • Steps to reproduce (a proof-of-concept is appreciated).
    • The affected URL / endpoint / component / version.
    • Your name and a contact channel for follow-up (optional but appreciated).

    Response targets

    Acknowledgement
    within 2 business days.
    Initial assessment
    within 5 business days.
    Mitigation
    driven by CVSS severity — critical issues are prioritized for same-week patching; lower-severity items are tracked in our internal backlog with a documented remediation target.
    Confirmed personal-data breaches
    we notify affected customers within 72 hours per our DPA and our Privacy Policy.

    Scope

    In scope

    • sprintrr.ai and *.sprintrr.ai web properties.
    • The hosted MCP API at https://www.sprintrr.ai/api/mcp.
    • The @sprintrr/mcp-server npm package.
    • Our source code, CI workflows, and dependencies.

    Out of scope

    Please do not test against these — report to the upstream owner instead:

    • Third-party services we depend on (Supabase, Vercel, Anthropic, OpenAI, Google, Polar, Resend, Cloudflare, Upstash) — report to the vendor.
    • Denial-of-service or volumetric attacks.
    • Social engineering of our staff, contractors, or users.
    • Physical attacks against infrastructure, staff, or devices.
    • Attacks requiring physical access to a victim’s device.
    • Reports from automated scanners without a working proof-of-concept.
    • Missing security headers / cookie flags without a demonstrated impact.
    • Outdated TLS / cipher suites that are already disabled at the edge.

    Safe harbor

    We will not pursue legal action against researchers who:

    • Make a good-faith effort to comply with this policy.
    • Avoid privacy violations, destruction of data, and interruption or degradation of our services.
    • Only interact with accounts they own or accounts with the explicit permission of the account holder.
    • Do not exfiltrate data beyond what is necessary to demonstrate the vulnerability.

    Coordinated disclosure

    We follow the principle of coordinated disclosure. Please give us a reasonable window — typically 90 days — to remediate before publishing details. We will credit you in any related advisory unless you prefer to remain anonymous.

    What this is not

    This is a vulnerability disclosure policy. It is not a paid bug bounty — we do not currently offer monetary rewards. We may revisit that decision as the security program matures.

    Other channels

    General support / privacy / data subject requests
    support@sprintrr.ai
    RFC 9116 contact file
    /.well-known/security.txt

    Effective May 17, 2026. This policy may be revised; the version on this page is always current.