Responsible
Disclosure

We take security seriously and welcome reports from the security research community. This page describes how to report a vulnerability, what is in and out of scope, what to expect from us in response, and the safe-harbour commitments that apply to good-faith research.

1. How to Report

Email [email protected] with subject line [SECURITY] <short title>. Do not include live credentials, personal data, or an unredacted exploit in the first email. Ask for an encrypted channel and we will arrange one after acknowledging the report.

A good report includes:

• Affected endpoint or component (e.g. /v1/evaluate, /api/login, the dashboard, the SDK).
• Vulnerability class (e.g. SSRF, XSS, IDOR, auth bypass, business-logic flaw).
• A clear reproduction (request/response, steps, screenshots, proof-of-concept code).
• Impact assessment — what an attacker can achieve.
• Your suggested remediation, if any.

Please do not file vulnerability reports through public channels (GitHub issues, X, LinkedIn) before we have had a chance to respond.

2. Scope

In scope:

• sntlhq.com and its subdomains owned by Sentinel Edge Networks LTD (e.g. mr.sntlhq.com).
• The Sentinel REST API at /v1/* and /api/*.
• The Sentinel client-side SDK loaded from our origin or our CNAMEs.
• Account-management surfaces (signup, login, password reset, 2FA, OAuth, account deletion).

Out of scope:

• Vulnerabilities in third-party services we depend on (Cloudflare, Railway, Turso, Resend, Google, and our network- and device-intelligence providers) — please report those to the respective vendor.
• Issues that require a victim to install untrusted browser extensions, run untrusted JavaScript, or fall for unrelated phishing.
• Reports based solely on automated scanner output without proof of impact.
• Self-XSS, lack of rate-limiting on non-sensitive endpoints, missing security headers without a demonstrable exploit, "best-practice" findings (e.g. CSP not strict enough) without an exploitable consequence.
• Denial-of-service via volumetric attack, social engineering, physical access.
• Email spoofing or DMARC/SPF nits without a real attack.
• Issues only reproducible on out-of-date browsers (older than the last two major versions of Chrome, Firefox, Safari, Edge).

3. Response Targets

We are a small team in open beta — we will be honest about timing rather than promise enterprise SLAs we cannot meet. Our targets:

Stage	Target
Acknowledgement of report	Within 2 business days
Initial triage + severity assessment	Within 5 business days
Critical-severity remediation	Best-effort within 14 days; mitigation faster
High-severity remediation	Within 30 days
Medium / Low remediation	Best-effort, no fixed timeline
Public credit (if requested)	After fix is deployed and verified

4. Safe Harbour

Sentinel authorises good-faith security testing of the in-scope assets listed above, only within the limits of this policy. If you comply with those limits, Sentinel will:

• Treat the research as authorised by Sentinel and not initiate or support legal action by Sentinel for accidental, good-faith violations that arise directly from compliant testing.
• Waive the conflicting restrictions in our Terms of Service for activity that is exclusively in scope, reasonably necessary to establish the issue, and stops at proof-of-concept.
• Work with you to understand and resolve the issue quickly, and acknowledge your contribution publicly if you wish.

"Good faith" means: making a sincere effort to avoid privacy violations, service degradation, and data destruction; stopping testing as soon as the vulnerability is established; not exfiltrating customer data beyond the minimum needed to demonstrate the issue; not using the access to pivot into other customer data or systems.

This policy cannot authorise testing of systems owned by customers or third parties and cannot bind law enforcement, prosecutors, regulators, vendors, or any other third party. It does not immunise conduct that is unlawful or outside this policy. If you are unsure whether a test is covered, contact us before proceeding.

5. What We Ask You Not to Do

• Test on accounts that are not your own without explicit written permission.
• Run automated scanners that generate destructive traffic.
• Phish, social-engineer, or pretext our staff or customers.
• Access, modify, or delete data that does not belong to you.
• Disclose the vulnerability publicly before a coordinated disclosure date is agreed. We normally aim to resolve disclosure within 90 days, but may agree an earlier or later date based on severity, exploitation, and remediation complexity, with status updates during the process.

6. Bug Bounty

We do not currently run a paid bug-bounty programme. We are happy to publicly credit researchers, send Sentinel-branded swag for substantial reports during beta, and open a discussion about a paid programme as we move toward general availability. If you are seeking a paid bounty up front, please mention this in your initial email so we can be transparent about expectations.

7. Other Trust & Compliance Signals

• Privacy & Data Processing: see our Privacy Policy for what we collect, retain, and process.
• Cookies and SDK behaviour: see our Cookie Policy. The current sub-processor list (Cloudflare, Railway, Turso, Resend, Upstash, Amazon Web Services / S3, Google and GitHub Sign-In, Have I Been Pwned, plus our network- and device-intelligence providers, named to customers under DPA) is maintained at /sub-processors with a dated change log.
• Customer terms: see our Terms of Service. A DPA is available to every customer whose integration involves Sentinel processing personal data — published self-serve at /dpa, with countersigned copies by email from [email protected].
• Audit posture: Sentinel is in open beta. We are pre-audit for SOC 2 Type II and will publish the audit firm and scope when an engagement is signed. Until then any compliance claim on the site reads "pre-audit", not "certified".
• Sub-processor change notification: we will notify customers via the dashboard and email at least 30 days before adding a new sub-processor that processes customer data, allowing time to object before the change takes effect.

8. Researcher acknowledgments

We publish researcher names or handles here only with their permission after remediation. No public acknowledgments have been requested yet.

9. Contact