Edge
One API surface
A single API service is the only writer to the database and the only thing the reader fleet talks to. Every request is validated against typed, strict schemas.
Trust center
Security you can review, not just believe.
The strongest claim we make is structural: the platform cannot leak patron identity because it never holds patron identity. This page is the operational side of that claim — how the system is built, what it stores, who processes it, and how your security team can verify all of it.
01 · The storage boundary
What the platform holds — and refuses.
Ingestion contracts are allowlists, not blocklists: a device that sends an unrecognized field gets a rejection, not a silent strip. There is no patron table for a breach to expose.
Data class Platform stance
operational data Organizations, locations, devices, activation state, fleet health, team roles
verification data Aggregate counters only; every report row suppressed below k=3
trust material Lifecycle status only — never key or certificate material in the operational store
patron identity No entity, no column, no log — rejected at the ingestion contract
credential payloads Never cross the device boundary at all
02 · Architecture in brief
Small surface, few moving parts.
Identity
Passwordless staff auth
Portal sign-in uses hosted, standards-based authentication with magic links — no passwords set, stored, or phished. Roles scope every view and action.
Observability
Scrubbed by rule
Error reporting is configured so device-ingestion failures never capture raw request bodies. An error is not an exemption from the never-store list.
03 · Subprocessors
Who touches the operational data.
Laurel runs on a small set of infrastructure providers. None of them ever receive patron identity, because the platform itself never has it.
| Provider | Function | Data involved |
|---|---|---|
| Cloudflare | Edge hosting, API runtime, DNS | Operational traffic |
| Neon | Postgres database | Operational records, aggregate counters |
| WorkOS | Staff authentication (AuthKit) | Staff work emails and sessions |
| Stripe | Reserved; pilot automation inactive | No pilot data processed |
| Resend | Transactional email | Staff notification emails |
| Sentry | Error monitoring | Scrubbed operational errors |
Patron identity does not appear in this table because it does not exist on the platform to share.
04 · Security review pathway
Bring your security team. We planned for them.
-
Documentation package
Architecture overview, the data-classification table for every stored field, and the privacy-boundary spec your reviewers can test claims against.
-
Review session
A working session with the engineering team — data flows, tenancy, auth model, and the ingestion allowlists — with your questions driving the agenda.
-
Findings and follow-through
Written responses to findings before the pilot goes live. Security review is a standard leg of pilot qualification, not a favor.
05 · Disclosure
Found something? Tell us directly.
If you believe you have found a security issue in Laurel Secure, contact us through the contact form with enough detail to reproduce it, and mark the message as a security report. We acknowledge reports, keep you informed while we investigate, and do not pursue good-faith research.