Paloryx Labs
Legal

Security

How we keep your data safe, how we sign you in, and how to report a vulnerability.

Last updated: April 19, 2026

Our approach

Paloryx is a security product, and our customers operate in regulated environments — healthcare, legal, defense, financial services, education. We treat our own security the way they treat theirs: privacy by default, least-privilege everywhere, no clever tricks that can go wrong quietly. The resolver runs on your hardware, detection happens entirely on-premises, Paloryx Labs never receives or stores your DNS queries, and our cloud only receives what it’s explicitly asked to receive.

This page documents the security posture of the cloud-side services and the resolver itself. If you need answers to a formal vendor security questionnaire, please reach out.

Data in transit

  • All traffic between the resolver and our cloud is encrypted with TLS 1.2+, with TLS 1.3 preferred. Certificates are validated against the public trust store — no pinning exceptions.
  • The resolver supports encrypted DoH / DoT for upstream resolution — no plaintext DNS crosses the public internet.
  • The web dashboard at paloryxlabs.com enforces HSTS and modern TLS ciphers.

Data at rest

  • Account and license data lives in Supabase on AES-256 encrypted disks. Per-row access is enforced with Row-Level Security on every table that contains user data.
  • Device API keys are stored as SHA-256 hashes, never in plain text. A leaked database row cannot be used to impersonate a device.
  • Passwords for optional Paloryx Labs accounts are hashed with Argon2id (Supabase's default) and never logged.
  • Payment data is stored by Stripe. We never see or store full card numbers.

Authentication

  • Owner console: the admin UI at paloryxlabs.com requires multi-factor authentication (TOTP, AAL2) and is gated to a single owner email plus a specific admin subdomain.
  • Customer dashboard: supports password and email magic-link sign-in, both via Supabase Auth.
  • Resolver admin UI: the local web UI at 127.0.0.1:8787 requires a username + password set on first run. Admins can enable TOTP for an extra factor.
  • Device activation tokens: one-time tokens issued by the dashboard. They're consumed the first time a resolver uses them; they can't be replayed.

Network security

  • Where the host platform doesn’t expose a fine-grained privileged-port capability, the daemon runs as rootto bind port 53 — the same posture taken by most DNS resolver software. The daemon’s C-language dependencies are limited to the shared library backing the semantic-detection layer (an open-source ONNX runtime) and system libraries.
  • Software updates are delivered via signed manifests from our cloud and verified by SHA-256 before being applied.

Threat detection — what does and doesn’t reach Paloryx Labs

The threat-scoring stack (heuristic + lexical + semantic) and the reference banks of malicious / legit / brand indicators are bundled in the installer and run entirely on the resolver. No DNS query is sent to Paloryx Labs for scoring under any circumstance. DNS resolution itself goes to whichever upstream you configure (your existing DNS, an internal recursive resolver, or any public resolver) — that destination is your choice and is never us.

For Pro deployments that opt in, the resolver MAY send a 4-byte SHA-256 prefix of a query to our threat-intel service when the local score lands in a configurable uncertainty band. This is a k-anonymized lookup: we receive the prefix and return the matching hash bucket. Reconstruction of the original query name from the prefix is not mathematically possible — there are millions of domain names that share any given 4-byte prefix.

The optional cloud lookup can be disabled via resolver settings, in which case the detection stack continues to operate at full local capability without it.

Threat-bank deltas (daily refresh of the malicious bank from public sources) are pulled from our cloud over signed manifests. Bank pulls are zero-data-out: we transmit bank updates to you, and the resolver sends nothing back beyond the request itself.

Audit and monitoring

  • Admin actions in the owner console are written to an append-only audit log that includes actor, action, target, and timestamp. The resolver's local admin UI similarly logs every policy and user change.
  • Infrastructure alerts (auth failures, unusual billing events) go to a private channel monitored by the team.

Vulnerability reporting

If you discover a security issue in Paloryx Resolver or our cloud, please email security@paloryxlabs.com. We'll acknowledge your report within 72 hours and aim to provide an initial assessment within 5 business days.

Please don't publicly disclose the issue until we've had a chance to ship a fix. We'll credit you in the release notes unless you prefer anonymity. We don't currently run a paid bug-bounty program but will consider one-off rewards for high-severity issues.

Scope

  • Paloryx Resolver (all tiers).
  • paloryxlabs.com, paloryxlabs.com/dashboard.
  • Our public API under /api/v1/*.

Out of scope

  • Denial-of-service attacks or load testing without prior written permission.
  • Findings that require physical access to a device the resolver runs on.
  • Social engineering of Paloryx Labs employees or customers.
  • Self-XSS, clickjacking without a demonstrable security impact, missing security headers without an exploit.

Incident response

If we become aware of a security incident that affects your data, we will notify you via email within 72 hours of confirming the scope, describe what happened in plain language, and lay out the steps we took. We publish post-mortems for significant incidents on this page.

Questions

General security questions: security@paloryxlabs.com. Privacy questions: see our Privacy Policy.