Skip to content

Security and trust

What the design is intended to guarantee, stated as outcomes. Where something is not yet settled, this page says so rather than implying otherwise.

What the design is meant to guarantee

  • One organization cannot reach another's data

    Tenant isolation is enforced in four independent layers rather than one, so a mistake in any single layer is not sufficient to cross the boundary. A request for another organization's data is designed to be indistinguishable from a request for data that does not exist.

  • Access follows your records, not a job title

    A granular permission catalogue combines with record-level scopes, so what someone can reach is derived from your reporting lines, group membership and project membership, and re-derived on every request rather than baked into a token.

  • Losing access is immediate

    Deactivating an employee cuts their access on the next request. Local state is authoritative, so a still-valid credential issued earlier does not keep a door open.

  • Consequential changes leave a record

    An append-only audit trail captures who did what, when, and what the value was before and after. Approved time is immutable, so a correction is a new attributable event.

  • We hold no passwords

    Authentication runs through a dedicated identity provider. LynxSprint stores no password hashes and mints no production credentials of its own.

  • The application has no inbound network exposure

    The service is published through an outbound tunnel with no inbound ports open on the host, and that is verified by external scan rather than assumed.

  • AI cannot exceed the person who invoked it

    Agents receive no database credentials and act only through registered tools that carry the same authorization checks as a human request. Consequential actions require a recorded human approval.

  • Sensitive fields are protected separately

    The most sensitive employee fields are encrypted at the application layer with their own key handling, separately permissioned, redacted by default in list responses, and excluded from AI contexts at the tool layer.

What we do not claim

Most security pages leave this section out. It is the part worth reading, and it is how you can tell whether the rest of the page is doing the same thing.

No certifications yet

We hold no SOC 2, ISO 27001 or equivalent certification. The controls are designed against those frameworks and we intend to certify, but we have not been audited and we are not going to imply that we have. When it changes, this page carries the date and the scope.

No published SLA

We do not publish an availability target. An uptime number is a contractual statement, and it belongs in a contract that we negotiate with you rather than on a marketing page. Ask us and we will tell you what our current posture is.

Data residency on request

We do not publish a region list. Naming some regions and estimating others produces a claim that is wrong in exactly the way a procurement review catches. Ask us about your requirement and we will answer it specifically.

Who else is involved

The services LynxSprint depends on, what each is for, and what it touches. The maintained version, with change notice, is the sub-processors page.

Service Purpose What it touches
Cloudflare, Inc. DNS, CDN, TLS termination, static site hosting, and the tunnel that publishes the API Request metadata (IP address, user agent) in transit. No application data at rest.
Supabase Authentication provider — sign-in, sessions and token issuance Email address and authentication metadata. No employee, project or time data.
Amazon Web Services (SES) Transactional email — verification, invitations, reminders Recipient email address and message content
Hostinger Human mailboxes for role addresses, and domain registration Correspondence you send us
Anthropic Large-language-model provider for the optional AI features Only what a permitted tool returns, for organizations that have opted in. Off by default; no data is sent when AI is disabled.

Found something?

We would rather hear about it from you than from an incident. The responsible-disclosure page sets out how to report it and what we commit to in return.