LumaLayer trust center

Security

This page is maintained by LumaLayer to answer common security questions about the workspace. It describes controls that are enabled in the product today. It is not an independent audit, and it is not a certification.

Last updated October 21, 2026Plain-language— sections

In short

Every student record is locked to its clinician and caseload team, files sit in private storage behind short-lived links, names are removed before AI drafting by default, and every export is logged.

Access and authentication#

  • Anyone can create an account with a confirmed email address or Google. Each new account gets its own private workspace; it cannot see another workspace's students or records unless an administrator of that workspace invites it.
  • Sign-in is email-and-password or Google, handled by our managed authentication provider; we never store your password.
  • Roles are held separately from user profiles, so a user cannot escalate their own permissions.
  • Sign-in events are recorded so unexpected access can be spotted.

Data separation#

Every student, IEP, goal, session and recording row carries an owner. Row-level security policies in the database restrict reads and writes to the creating clinician, clinicians assigned to that caseload, and organization administrators. The rules are enforced by the database on every request, including requests made by the application itself.

Recordings and files#

  • Session recordings and imported IEP documents are held in private storage, never in a public bucket.
  • Files are reachable only through short-lived signed links issued to an authorized clinician.
  • Recording and AI transcription require a per-student consent record to be tracked in the consent ledger. In the current release the ledger is informational: a missing consent does not block a session, but every AI-generated artifact produced without one is flagged for audit.

Encryption and transport#

All traffic to the application is served over HTTPS. Data at rest is encrypted by our managed cloud database and storage providers.

Where data is stored#

Workspace data is stored and processed in the United States. The full list of companies that process data for us is on our Privacy Policy.

Privacy & de-identification#

De-identify mode is on by default. Identifiers in imported IEP text, transcripts and generated notes are replaced with stable per-student tokens before the text reaches an AI model or long-lived storage. Clinicians still see real names, because the app re-inserts them at display time from a restricted token map. Each ingestion pauses on a review panel so a clinician confirms what will be replaced, and every event is written to an identifier-free privacy audit that owners can export.

Read how de-identification works.

Audit trail#

Exports, disclosures, approvals and AI-output reviews are written to an append-only audit log with the acting user and timestamp. Audit entries cannot be edited or deleted from the application.

AI safeguards#

  • Generated documents are drafts and are marked unapproved until a clinician reviews them.
  • The original generated text is stored alongside the clinician's final text, so edits are visible.
  • Student data and audio are never used to train, retrain or fine-tune AI models.
  • AI requests are rate-limited per user to contain runaway usage.

Incident notification#

If we confirm a security incident affecting student data, we notify the affected district or practice in writing within 72 hours of verifying it, with what happened, what data was involved and what we are doing about it.

Shared responsibility#

We secure the platform: access control, storage, encryption in transit and audit logging. Your organization is responsible for who you grant access to, for obtaining the consents required before recording a student, and for reviewing generated documentation before it leaves the workspace.

For districts#

District privacy and IT teams can download our data protection packet, including the National Data Privacy Agreement and state riders, on District resources.

Reporting a vulnerability#

Report suspected vulnerabilities or a security incident to security@lumalayer.ai. We acknowledge reports within two business days and do not pursue researchers who report in good faith.

Questions about this page? Our team answers directly.

hello@lumalayer.ai