Aletheia Security Whitepaper

1. Overview

Aletheia is a user-side accessibility tool. It runs optical character recognition, generates image descriptions, restructures content, and labels forms, then exports the result as tagged PDF or plain text and reads it aloud in the browser. Most of that work happens in the user's own browser, on the user's own device. The security posture follows from that architecture: the less data that leaves the device, the less there is to protect in transit or at rest, and the smaller the surface an attacker or an over-broad administrator can reach.

Where data does leave the device, it is limited to what an account needs to function: an identity from an OAuth provider, plan and billing status, and the usage counts needed to enforce plan limits. User documents are not stored on Lonia infrastructure. Authentication is OAuth single sign-on only, with no password anywhere in the system. Every database table is protected by row-level security so a user can reach only their own rows, and privileged institutional actions are recorded to an append-only audit log that cannot be edited or deleted.

Every control described in this document applies to every tier, including the permanent free tier. Security is treated as infrastructure, not as an upgrade. The sections that follow describe each layer, the honest limits of Aletheia's current compliance posture, and how to report a security concern.

2. Identity and Access

Authentication is OAuth single sign-on only, through Google Workspace or Microsoft 365, on every tier including Free. There is no email-and-password login anywhere in the product: no password field, no password reset flow, and no password to store, leak, or phish. Sessions are managed by Supabase Auth. Because sign-in is delegated to the identity provider, Aletheia never holds a credential that can be reused elsewhere.

Institutional deployments separate administrator authority into distinct roles so that access follows least privilege:

• Primary administrator: full management of the institutional account, seats, and other administrators.
• Secondary administrator: day-to-day seat and license management without the ability to remove the primary administrator or change account-level settings.
• Read-only administrator: visibility into seat counts and aggregate usage for reporting, with no ability to change state.

Administrators see aggregate metrics only, with small cohorts suppressed server-side; no individual-student surface exists.

3. Data Protection at Rest

Account data stored in Supabase PostgreSQL is encrypted at rest with AES-256, managed by the database platform. This covers the identity, plan, and usage records that make up an account, on every tier.

On the Professional tier, a user may connect their own AI provider key (bring your own key). That key is stored in the browser using a non-extractable key held in IndexedDB and encrypted at rest with AES-GCM-256. Non-extractable means the key material cannot be read back out of the browser's key store by page script; it can only be used to encrypt and decrypt locally. On Professional the provider key never leaves the device and is never transmitted to Lonia.

On the Enterprise tier the model is institution-managed and server-side. An institution administrator enrolls one organization API key with Lonia's Enterprise Worker over TLS. The Worker envelope-encrypts the key with a master key, and the wrapped key is stored encrypted at rest in Supabase (aletheia_institutions.institution_byok_encrypted_key). The Enterprise key material is never returned to any client: not to seat browsers, not to administrator browsers, and not to Lonia staff. User documents on both tiers are processed in the browser and saved to a local library on the device; they are not written to Lonia infrastructure at rest.

The Supabase primary data store is hosted in a single United States region. A future migration to an EU region is under consideration but not scheduled. The transfer analysis for institutional data at rest is set out in the Data Protection Impact Assessment and referenced in the Data Processing Agreement.

4. Data Protection in Transit

All network endpoints are served over TLS 1.3. Cloudflare terminates TLS at the edge in front of the static site (Cloudflare Pages) and the serverless functions (Cloudflare Workers), and connections onward to Supabase are likewise encrypted. HTTP Strict Transport Security is set with preload on every surface, so browsers refuse to connect over plaintext: the marketing site sends a two-year max-age and the application surfaces send a one-year max-age.

On the Professional tier, the bring-your-own-key path is deliberately architected so that the user's provider key and the content they choose to describe travel browser-direct to the AI provider (Anthropic, OpenAI, or OpenRouter). The request goes from the user's browser straight to the provider the user configured. It does not transit Lonia infrastructure, Lonia does not proxy or intermediate it, and Lonia never sees the key or the content. This is shown as the Professional (browser-direct) path in the data flow diagram below.

On the Enterprise tier the path is Lonia-mediated. An Enhanced AI request runs from the seat's browser to Lonia's Enterprise Worker (a Cloudflare Worker) over TLS 1.3; the Worker decrypts the institution's enrolled key in memory for the lifetime of that request only, calls the AI provider on the institution's behalf, and returns the description. The institution's request content therefore transits Lonia infrastructure to the provider on this tier. The Worker does not persist the image beyond the synchronous request and response, and never returns the key material to any client. This is shown as the Enterprise (via Cloudflare Worker) path in the data flow diagram below.

The Personal and Family tier Enhanced AI path is different: it is Lonia-mediated, routing the single image a user chooses through a Lonia Cloudflare Worker to OpenRouter (United States hosted) over TLS 1.3, with no image content logged in the Worker and no image persisted server-side beyond the synchronous request and response. That cross-border transfer is covered by the scoped Standard Contractual Clauses and evaluated in the Transfer Impact Assessment.

5. Row-Level Security

Row-level security (RLS) is enabled on every table in the Supabase database, with no exceptions. A signed-in user can read and write only the rows that belong to them; there is no query path that returns another user's rows. Institutional data is scoped by an institution_id so that an administrator's reach is bounded to their own institution, and student-scoped tables carry that foreign key from creation.

Administrators see aggregate metrics only, with small cohorts suppressed server-side; no individual-student surface exists. The default for every institutional administrator is aggregate-only visibility.

6. Audit Logging (WORM)

Significant user actions and every institutional administrator action are written to append-only audit logs: aletheia_audit_log for user-level actions and aletheia_institutional_admin_audit_log for administrator actions. These tables are write-once, read-many (WORM): their row-level security policies permit inserts and reads but define no UPDATE and no DELETE policy, and write-once triggers refuse any update or delete, so an existing audit record cannot be altered or removed, including by an administrator. Privileged operations emit their audit records through server-side remote procedures, so the act of performing the operation and the act of recording it are bound together rather than left to the caller.

Hash chain. Every row in both audit tables carries the hash of the previous row and its own SHA-256 hash, with the chain version inside the hash, so a row cannot be altered, removed, or inserted out of order without breaking the chain from that point on. Verification runs inside the database: a function walks the chain and returns whether every link holds. Write-once triggers refuse any update or delete on the audit tables; the one exception is the account-deletion pseudonymisation described in Section 9, which replaces the identity with a one-way code rather than removing the row. A scheduled check (the aletheia-audit-chain-verifier Worker, daily at 03:30 UTC) runs the verification over aletheia_audit_log and aletheia_institutional_admin_audit_log and records its verdict, and a break is reported to support@lonia.ai. Institution administrators can run the same verification from their dashboard.

Healthcare Mode. Medical documents (intake, consent, insurance and history forms, medication labels and guides, patient-portal pages, appointment and visit summaries, bills and Explanations of Benefits) are recognised and read on the user's device. Nothing medical enters the user's saved profile, which has no medical field, and no medical content is stored on Lonia infrastructure. A form fill copies each value the user confirms, one field at a time, and never offers a value for a medical question or a signature. Before any Enhanced AI upload of such a document, a consent prompt names the kind of document. Two audit actions record the mode: autofill_applied, one row per confirmed field, naming the profile field and never its value, and patient_portal_scan_consented, written when the user accepts the consent prompt. autofill_applied is admitted by the audit-vocabulary CHECK constraint described above, and an unknown action name is refused.

7. Data Retention

Retention for institutional deployments is configurable per institution, with a default of 365 days, stored as retention_days on the institution record. A Cloudflare Worker (the aletheia-retention-cleanup Worker, daily at 03:00 UTC) deletes student-scoped data that has passed the institution's retention window. Retention is enforced by that scheduled job, not merely recorded as a preference: when the window elapses, the data is removed.

Consumer billing records. When a consumer account is deleted, one billing record is written for each subscription that was cancelled. It holds the Stripe customer and subscription reference numbers, the plan, the billing period, and the cancellation date, and holds no name, no email address and no account identifier. It is deleted automatically seven years after the cancellation, and its basis is GDPR Article 17(3)(b), a legal obligation for tax and accounting records, and Article 17(3)(e), the establishment or defence of legal claims. Lonia and Stripe can link those reference numbers back to a person, so the record is pseudonymous rather than anonymous and is protected as personal data for the whole seven years. This is the only account data that outlives a deletion, apart from the security log described in Section 9.

8. Sub-processors

The following third parties process data on Lonia's behalf to operate Aletheia. Each is limited to the purpose listed.

Bring-your-own-key AI providers are treated per tier. On the Professional tier the user's browser calls the provider the user configured directly, under the user's own account and terms, so no user key or content passes through Lonia to that provider, and the provider is not a Lonia sub-processor. On the Enterprise tier the institution's key is enrolled with Lonia's Enterprise Worker, which relays Enhanced AI request payloads to the institution-selected provider on the institution's behalf; for that path the provider receives content via Lonia infrastructure and is engaged as a Lonia sub-processor, listed in the table above. OpenRouter can therefore hold up to three roles depending on the path: a Lonia sub-processor on the Lonia-mediated Enhanced AI path for Personal and Family; a Lonia sub-processor on the Enterprise institution-managed bring-your-own-key path when an institution selects it; and a user-invoked provider that is not a Lonia sub-processor on the Professional browser-direct bring-your-own-key path. The authoritative, versioned list, with the update-on-change and advance-notification policy, is published at the Sub-processor List.

9. Data Deletion

Cancellation first, or nothing is deleted. Deleting an account cancels the subscriptions before it deletes anything. The deletion path finds every Aletheia subscription held for that person, on the account record and on every Stripe customer carrying that person's email address, cancels each one, and reads each one back from Stripe as cancelled. If any lookup, cancellation or read-back fails, the deletion does not proceed: nothing is removed, and the person is told the account could not be closed because the cancellation was not confirmed, so they can try again. A Campus or Enterprise subscription is not cancelled by a personal account deletion, because it belongs to the institution.

Once every cancellation is confirmed, the identifying account-level data Lonia holds is deleted by cascade: the identity, plan, and usage counts associated with the account are removed. Two records survive, and only two. The first is the pseudonymous billing record described in Section 7, kept for seven years under GDPR Article 17(3)(b) and (e) and protected as personal data throughout, because the reference numbers in it remain linkable to a person by Lonia and by Stripe. The second is the security log, retained with the person's identity replaced by a one-way code and identifying details removed. Because user documents live in the local library on the user's device and were never stored on Lonia infrastructure, there is nothing on the document side for Lonia to delete. Append-only audit records are preserved as required for compliance and retained per the applicable retention policy; they record that actions occurred without retaining the underlying documents.

A failed payment is not a deletion. When a payment fails, the account moves to the free plan immediately and nothing is deleted: the local library and every document in it are untouched, and the account continues at the free plan's limits. Two emails are sent, one at the time and one three days later. There is no third notice and no grace period; the paid plan returns when a payment succeeds.

10. Compliance Posture

Aletheia's compliance posture is stated plainly, including what it does not hold.

• Accessibility: WCAG 2.2 Level AA is the conformance target, with Section 508 alignment. Aletheia publishes a VPAT accessibility report, a European Accessibility Act conformance statement, and an EN 301 549 conformance mapping. Accessibility status is self-evaluated; a formal third-party accessibility audit is planned but has not yet been conducted.
• FERPA: the data-segmentation architecture described above (institution scoping, per-institution retention, and append-only audit logging) is built in and available for education deployments.
• SOC 2: Aletheia is not SOC 2 audited and claims no SOC 2 attestation.
• ISO 27001: Aletheia holds no ISO 27001 certification.
• HIPAA: Aletheia claims no HIPAA compliance certification. For healthcare Enterprise deployments the product includes architectural detection of personally identifiable information; detection is an architectural feature, not a certification, and no HIPAA compliance is claimed.

All security and compliance statements in this whitepaper are based on self-evaluation. No third-party security audit has been performed.

11. Incident Response

Suspected vulnerabilities and security concerns can be reported to support@lonia.ai. Security reports are acknowledged within 3 business days; acknowledgement is a reply from a person, not a resolution time. Where a security incident affects personal data processed for an institutional customer, notification follows the timeline in the applicable Data Processing Agreement, which reflects the 72-hour notification expectation of GDPR Article 33.

12. Data Flow Diagram

The diagram below shows the standard request path from the browser through Cloudflare to Supabase, and the two bring-your-own-key paths: the Professional path, in which the browser calls the AI provider directly and bypasses Lonia infrastructure, and the Enterprise path, in which the request runs from the browser through Lonia's Cloudflare Worker to the AI provider. A text description follows the diagram.

In words, the flow is:

1. The user's browser processes documents on the device and, for account and billing operations, connects over TLS 1.3 to Cloudflare.
2. Cloudflare Pages serves the static site and Cloudflare Workers run the serverless functions; Workers connect over TLS to Supabase.
3. Supabase holds the PostgreSQL database (with row-level security on every table) and manages authentication.
4. On the Professional bring-your-own-key tier, when the user chooses to use their own provider key, the browser calls the AI provider directly. That request bypasses Cloudflare and Supabase and never reaches Lonia infrastructure, so Lonia never sees the key or the content.
5. On the Enterprise bring-your-own-key tier, the institution's key is enrolled once with Lonia's Enterprise Worker and stored envelope-encrypted at rest. When a seat makes an Enhanced AI request, it runs from the browser to the Enterprise Worker, which decrypts the key in memory for that request only and calls the AI provider on the institution's behalf. The key material is never returned to any client.

13. Change History and Review Cadence

This whitepaper was published on July 14, 2026 for Aletheia version 1.0.0. Last review date: September 24, 2026. Next review: annually, or on material change, whichever comes first. Material changes include an architecture change, a sub-processor change, and a relevant regulatory change. The review is owned by privacy@lonia.ai, in coordination with support@lonia.ai, and on each review this page and the tagged PDF are regenerated together from the same source.

Related documents

• Security whitepaper (tagged PDF)
• HECVAT 4.1.6 response (pre-completed higher-education vendor assessment)
• Data Processing Agreement (DPA) template
• Data Protection Impact Assessment (DPIA)
• Scoped Standard Contractual Clauses (SCCs)
• Transfer Impact Assessment (TIA)
• Privacy policy
• VPAT accessibility report
• European Accessibility Act (EAA) conformance statement
• EN 301 549 conformance mapping