Sentinel Edge Networks LTD (company number 17150600) is responsible for this notice. We are the controller for account, website, support, business-contact, service-security, abuse-prevention, and pseudonymous service-wide device-sighting data where we determine why and how that data is used. When a customer sends end-user data to the Sentinel API for its own fraud decisions, the customer is normally the controller and Sentinel acts as its processor under the customer’s instructions. The customer remains responsible for its decision rules and notices to its users.
This notice explains what personal data we receive, where it comes from, why we use it, how long we keep it, who receives it, and the choices available to individuals. It applies to sntlhq.com, Sentinel accounts, support interactions, and the Sentinel API and SDK.
1. Data We Collect on Behalf of Customers
When an End-User interacts with a Customer's platform protected by the Sentinel Edge SDK or API, we act as a Data Processor. We collect specific technical information required to determine whether a request originates from a legitimate human user, an automated bot, or a malicious actor. This data includes:
- Network Data: IP addresses, Autonomous System Numbers (ASN), proxy/VPN detection signals, and TCP/IP connection characteristics.
- Device & Browser Telemetry: User-Agent strings, browser version, screen resolution, language settings, hardware concurrency, canvas and WebGL fingerprints, and browser tampering indicators (antidetect browser detection).
- Behavioral Signals: Anomalous interaction patterns (e.g., highly rigid mouse movements or automated scrolling indicative of scripted bot activity).
- Device Intelligence: Incognito/private mode detection, virtual machine detection, emulator detection, and bot classification signals.
Customers may optionally send their own pseudonymous accountId so they can detect one device being used across multiple accounts. Sentinel hashes that value before storage. Customers are instructed not to use a name, email address, or other directly identifying value as an accountId. Customers may also optionally submit an end-user email address for a disposable-domain (“burner email”) check: the address is compared in memory against a public list of disposable-email providers and immediately discarded — only the resulting true/false flag is stored with the evaluation record, never the address itself. The fraud-detection API is not designed to receive passwords, payment-card numbers, names, or postal addresses.
End-user telemetry comes from the end-user’s browser or network request, from the customer integrating Sentinel, and from our network- and device-intelligence providers. The customer decides whether its end users are contractually or legally required to provide this data and must explain any consequences of not providing it.
What the stored evaluation record contains: each API evaluation is stored for the customer’s own dashboard as a row holding the IP address (one-way hashed after 7 days — see retention below), a two-letter country code, boolean signal flags (VPN, proxy, datacenter, anonymous network, bot, tampering, antidetect, incognito, burner-email flag), the returned risk score and decision, the network service classification label where one was identified (e.g. the VPN provider name), a coarse browser and operating-system label (e.g. “Chrome 150”, “Windows 11” — never a full User-Agent string), and a pseudonymous device key derived as a one-way SHA-256 hash of the device-intelligence identifier — the raw identifier itself is never stored. These records are visible only to the customer whose API key ran the evaluation and are never linked across customers.
1.1 Data We Collect From Our Own Customers
When you create a Sentinel account, we act as a Data Controller for your account data: your email address, a bcrypt hash of your password (never the password itself), the IP address used at signup and login (abuse prevention), API usage counts, any organization membership you configure, any alert-webhook URL you save (used only to deliver your threat alerts), and — if you add a passkey — the passkey's public key, credential identifier, and a device label you choose. A passkey's private key and your biometrics never leave your device; we store only the public half needed to verify sign-ins, and you can remove any passkey from the Security page at any time (removal is immediate). If you sign in with Google or GitHub, we store the provider's stable account identifier to link future sign-ins. If you lock a founding price from our pricing page, we record which plan you chose and when, solely to honor that price when billing begins. We also keep minimal service-notice bookkeeping (a count of rate-limit rejections and the time of the last limit notice we emailed you) so we can alert you when your API quota is nearly exhausted without repeating ourselves. For sign-in security alerts we store a one-way hash of the browser identifier (user-agent string) of each browser you have signed in from — never the raw string — so we can email you when your account is accessed from a browser we have not seen before; security notification emails (password changes, key rotation, passkey changes, new sign-ins) are transactional and cannot be disabled. If you configure a threat-alert webhook we also generate and store a signing secret so your endpoint can verify our deliveries. Evaluation records are retained for the life of your account (raw IP addresses are one-way hashed after 7 days as described below) and can be exported as CSV from the dashboard at any time; they are deleted with your account. Transactional email (OTP codes, password resets) is delivered through our email sub-processor. If you subscribe to our newsletter or use the free bulk IP-lookup tool, we record the email address you provide and the IP address of the request for consent and abuse-prevention records; you can unsubscribe at any time from the link in any newsletter. Account data is retained until you delete your account — deletion via the Security page removes your data from live systems immediately (GDPR Art. 17). Encrypted daily backups of account data, stored within the EU, expire on a rolling schedule of at most 60 days, after which deleted data is unrecoverable from backups as well.
2. How We Use the Data
The metadata collected is used exclusively for the purpose of securing our Customers' applications. Specifically, we use it to:
- Detect and block account takeovers (ATO), credential stuffing, scraping bots, and antidetect browser abuse.
- Identify high-risk infrastructure such as commercial residential proxies, TOR exit nodes, anonymous datacenters, and spoofed devices.
- Generate an abstract, mathematical "Risk Score" and device intelligence assessment returned to our Customer's API.
- Verify password safety against known breach databases using k-anonymity (partial hash only — actual passwords are never transmitted).
2.1 Lawful bases by purpose
- Providing accounts, authentication, support, and contracted services: performance of a contract or steps requested before entering a contract.
- Protecting Sentinel, our customers, and end users from fraud, abuse, account takeover, and security threats: our and our customers’ legitimate interests in network and information security, balanced against the limited and pseudonymous nature of the telemetry.
- Service administration, audit logs, troubleshooting, and improving detection quality: legitimate interests in operating a reliable and accurate security service.
- Tax, company, sanctions, and lawful disclosure obligations: compliance with legal obligations where applicable.
- Optional product or newsletter messages: consent where required. You may unsubscribe at any time using the link in the message.
We do not use special-category data to produce risk scores and ask customers not to submit it. We do not use end-user telemetry for advertising.
3. Data Retention and Anonymization
We believe in strict data minimization. End-user IP addresses and device fingerprints are temporarily stored in volatile memory at the edge for real-time analysis.
Logs retained for diagnostic and threat-intelligence purposes undergo one-way cryptographic hashing (e.g., SHA-256) within 7 days. We do not store raw PII longer than is absolutely necessary to verify and mitigate an active cybersecurity threat.
Exception pins: customers may configure explicit “always allow” or “always block” entries for a specific IP address or pseudonymous device hash. These are customer-managed policy configuration, stored until the customer removes them or deletes their account — they are not tracking records, and the device entry is the same one-way hash used elsewhere (the raw device identifier is never stored).
False-positive reports: when a customer reports an evaluation as incorrectly scored, we keep a copy of that single event’s technical details (IP address, pseudonymous device hash, decision) together with the customer’s note so we can investigate and tune detection quality. The IP address in a report is one-way hashed on the same 7-day schedule as evaluation logs, and reports are deleted with the customer’s account.
Device sighting counters: to power “how many times has this device been seen” signals (the times_seen API field and the visit counter in the homepage scanner demo), we store a one-way SHA-256 hash of a device identifier together with a counter and first/last-seen timestamps. The raw identifier is never stored, and no IP address, user-agent, cookie, or account information is attached to these records — they are pseudonymous device statistics that cannot be tied back to a person by us. Sighting records are automatically deleted after 90 days of inactivity.
Customer account data (Section 1.1) is additionally protected by encrypted daily backups stored within the EU (Stockholm region) for disaster recovery. Backups are retained for a maximum of 60 days on a rolling schedule and are only ever used for full-system recovery — never to restore data a customer has deleted.
4. Your data protection rights
Depending on your location and the lawful basis, you may have rights to access, correct, erase, or restrict personal data; receive portable data you provided to us; and object to processing based on legitimate interests or to direct marketing. These rights are not absolute and exemptions may apply. Where we rely on consent, you may withdraw it at any time without affecting earlier processing.
If Sentinel processed your data for one of our customers, contact that customer first because it controls the purpose of the processing. We assist customers with verified requests. For Sentinel account or website data, email [email protected]. We normally respond within one month and may ask for information needed to verify your identity.
Your right to object: you may object to processing based on legitimate interests, including fraud-prevention profiling, by contacting us or the relevant customer. The controller will stop unless it demonstrates compelling legitimate grounds or the processing is needed for legal claims.
4.1 Automated decision-making and profiling
Sentinel automatically analyses technical signals and returns risk indicators, reason codes, and a score to the customer. Sentinel does not decide whether an end user may open an account, complete a purchase, or access a customer’s service. Customers determine their own rules and should provide human review or a way to challenge decisions where their use of Sentinel could have a legal or similarly significant effect.
4.2 Children
Sentinel accounts and business services are not directed to children. We do not knowingly request children’s names or contact details through the fraud-detection API. Customers serving children remain responsible for the additional notices, safeguards, and lawful basis their use case requires.
4.3 California disclosures
We do not sell personal information and do not share it for cross-context behavioural advertising. Subject to applicable thresholds and exceptions, California residents may request access, correction, or deletion and may exercise rights without discriminatory treatment. Requests can be sent to [email protected].
5. Sub-processors and Security
We do not sell data to third parties. We share data with trusted sub-processors strictly to provide our service. All sub-processors are bound by Data Processing Agreements (DPAs) and follow industry-standard security practices.
- Network intelligence provider — network-layer threat intelligence: VPN, residential proxy, datacenter, and Tor exit detection. Receives IP address and an encrypted SDK token.
- Device intelligence provider — device-layer intelligence: tampering, antidetect-browser detection, bot/automation, emulator/VM detection. Receives device telemetry and IP address.
- Cloudflare — CDN, DDoS protection, and DNS. Receives request metadata and IP. Privacy.
- Railway — application hosting. Privacy.
- Turso — managed cloud database (libSQL) for account records and API keys. Privacy.
- Resend — transactional email (OTP codes, password resets, contact-form receipts). Privacy.
- Google Sign-In — optional OAuth authentication. Receives and returns the information needed to complete sign-in. Privacy.
- Have I Been Pwned — password breach check via k-anonymity. Only a 5-character SHA-1 prefix is transmitted; the password itself never leaves your device. Privacy.
Our specialised detection sub-processors are identified above by category rather than by name, as the composition of our detection stack is confidential security information. Customers receive the full named sub-processor list (including each vendor's privacy policy) as part of their Data Processing Agreement — request one at [email protected]. We give customers at least 30 days' notice before adding a sub-processor that processes customer data — the current list and a dated change log are published at sntlhq.com/sub-processors.
We implement automated bot detection and rate limiting to protect our platform. Automated or excessive access may be restricted. Data is stored encrypted in transit; account passwords are hashed with bcrypt; API keys are randomly generated with crypto.randomBytes.
5.2 International Transfers
Some sub-processors handle data outside the United Kingdom and European Economic Area, including in the United States. Where required, we use an applicable adequacy regulation or contractual safeguards such as the UK International Data Transfer Agreement/Addendum and EU Standard Contractual Clauses. Information about the relevant safeguard is available by contacting us.
5.3 Personal data breaches
We maintain technical and organizational measures to prevent personal-data breaches. If a breach affecting personal data we process as a controller is likely to result in a risk to individuals, we will notify the Information Commissioner’s Office without undue delay and, where feasible, within 72 hours of becoming aware of it, and will inform affected individuals where the breach is likely to result in a high risk to them. Where we process end-user data as a processor on a customer’s behalf, we will notify that customer without undue delay after becoming aware of a breach so they can meet their own notification duties, as set out in our Data Processing Agreement.
6. Contact and complaints
Questions and rights requests can be sent to our privacy contact:
134a West Hendon Broadway, London, NW9 7AA, United Kingdom · Company number: 17150600
To make a formal data-protection complaint, email [email protected] with the subject Data protection complaint and describe the processing and outcome you are concerned about. We will acknowledge the complaint within 30 days, investigate it without undue delay, keep you informed where an investigation takes longer, and explain the outcome and any action taken. We keep a record of complaints as required to demonstrate how they were handled.
If you are dissatisfied with our response, you may complain to the Information Commissioner’s Office at ico.org.uk/make-a-complaint, telephone 0303 123 1113, or to the data-protection authority where you live or work.