01 · The boundaryWhat leaves your device, and when
LumenQube is a desktop application first. The documents you open, edit and save live in your own filesystem, under your operating system account, and nothing about ordinary editing sends their contents to us. That is the default, and it is the thing every other claim on this page rests on.
Some features cannot work that way, because sending content is the feature. There are six of them, they are each something you choose, and this is all of them:
On your device
- Docs
- Sheets
- Design
- Video
- Notes
- Forms
- Apps
- Flow
- Agent
Eleven kinds of document, the context graph that links them, and anything your OS keychain is holding. None of it is synced to us, and none of it is what the chips below are about.
Ordinary editing — nothing crosses
Opening, editing, saving and exporting a file happens entirely on your machine. There is no background sync and no check-in on a document you never shared.
- Sent
- Nothing. Not the file, not its name, not its contents.
- Stays on your device
- Everything — the documents, the context graph, and anything held in your OS keychain.
- Who receives it
- No one.
AI — a prompt, and the selection it needs
You ask for something; the request goes through our managed backend to the model provider for that feature, and the result comes back to the document.
- Sent
- The prompt, plus the selection, file or recording the action operates on.
- Stays on your device
- The rest of the document, and every file you did not act on.
- Who receives it
- LumenQube's backend, then the model provider — listed by name.
Publish — a revision the web viewer can render
Publishing puts a copy where a browser can reach it. That is the feature; there is no version of it that keeps the content on your disk.
- Sent
- The revision the viewer renders, plus any passcode you set — stored only as a hash.
- Stays on your device
- Everything you did not publish.
- Who receives it
- LumenQube servers, and whoever holds the link until you revoke it.
Connectors — the query for the action you approved
A connected account is authorized separately, scoped to what you granted, and disconnectable at any time from Settings.
- Sent
- Only the query or content the approved action requires — not your library.
- Stays on your device
- Your credentials are not there to send: tokens live server-side, encrypted, never inside a document.
- Who receives it
- The provider you connected, under that provider's own terms.
Support — the logs, and whatever you attach
A report filed from inside the app carries diagnostics so we can investigate. You decide whether a document goes with it.
- Sent
- Diagnostic logs, plus any attachment you choose to add — and nothing you did not add.
- Stays on your device
- Every file you did not attach.
- Who receives it
- LumenQube support.
Account — who you are, and what you have used
The one crossing that is always on while you are signed in. It carries the account, not the work.
- Sent
- Your account record, allowance balance and usage counters.
- Stays on your device
- Your documents. Metering counts requests, not content.
- Who receives it
- LumenQube servers, and the payment provider at checkout.
Do not use AI, sharing, publishing, connectors or diagnostics with attachments, and your document contents never reach us at all. Use one, and only the content that feature needs is sent. The Privacy Policy is the field-by-field version of this paragraph.
02 · ControlsProtection across the document journey
Different features have different boundaries, so they are described one at a time rather than under a single claim. These describe how the product is built today; none of them is a certification or a guarantee.
Local files & device sessions
Your operating system is the first line of protection, and we do not work around it.
- Desktop editing is local-first and does not background-upload document contents.
- Signed-in session tokens use the operating system's protected storage where it is available.
- Sensitive Notes data and recordings can be encrypted at rest against your OS keychain.
- Autosave and crash recovery reduce the chance of losing work after an unexpected shutdown.
Accounts & authentication
Designed against the credential and session attacks that actually happen.
- Passwords are salted and hashed with scrypt. Plain-text passwords are never stored.
- Email verification and short-lived reset codes protect account recovery.
- Access and refresh tokens are signed, expire, and support per-session or account-wide revocation.
- Rate limits and lockout protections deter brute-force and email-abuse attempts.
- Google Sign-In is available as an alternative to a password you have to remember.
Sharing & publishing
The owner decides who reaches a cloud copy and what they may do with it.
- Shared revisions are encrypted at the application layer and again by the hosting platform at rest.
- Viewer, commenter and editor roles constrain what a collaborator can do.
- Public and restricted links can be revoked; optional passcodes are stored only as hashes.
- Authorization is checked server-side before an encrypted revision is opened for a viewer.
- Rotating the document key after an access change stops a previously distributed key from being useful.
Connectors & external services
Optional, separately authorized, and scoped to the action you asked for.
- OAuth tokens are encrypted at rest in authenticated AES-256-GCM envelopes.
- Connector credentials stay behind the server proxy — they are never placed inside a shared document.
- Consequential write actions require your explicit action or approval, not a background rule.
- Disconnecting a provider deletes our stored authorization for that connection.
- Third-party services remain governed by their own security and privacy terms.
PDF privacy tools
Security-sensitive PDF actions change the file, not only what it looks like.
- Secure redaction removes the matched content and can sanitize hidden carriers and metadata.
- Password protection and certificate signatures are available for supported workflows.
- Sanitization can strip metadata, embedded files, scripts, hidden layers and retained form values.
- Verify a redacted file before you distribute it. No automated pass is a substitute for looking.
AI processing
Only the content the action needs, through our backend, to the provider you are using.
- LumenQube does not use customer content as generalized model-training material. A provider's own data use, retention and permitted security or legal processing depend on the service and our account terms and settings.
- Provider retention is service- and feature-specific; we do not promise universal zero retention.
- AI output can be wrong. Review it before you rely on it; it is not professional advice.
- Do not submit content you are not permitted to share with a processor.
The mobile app
A signed-in companion, distributed through the platform's own review and signing.
- Ships through the platform app store, so it carries store review and platform code signing.
- Device permissions — microphone, photos, files — are requested in context and can be withdrawn in system settings.
- Session tokens use the platform keychain, and signing out clears the device's stored credentials.
- The mobile app reads a separate cloud memory set from the desktop; see Memory & context.
Need the data-flow detail rather than the control list? The Privacy Policy covers collection, subprocessors, retention, international transfers and your rights.
Read the Privacy Policy →03 · InfrastructureWhere it runs, and how it is kept running
The hosted half of LumenQube — accounts, allowances, shared revisions, the web viewer and the AI proxy — runs on Google Cloud Platform. We do not operate our own hardware, and we inherit that platform's physical, network and storage-encryption controls rather than reimplementing them.
Hosting & isolation
Managed, container-based services with no long-lived servers to patch by hand.
- Application services run as containers on Cloud Run from immutable, digest-pinned base images.
- Containers run as a non-root user, and dependency installs inside them are locked to a resolved manifest.
- Application data lives in Firestore and Cloud Storage under Google Cloud's encryption at rest. Shared document revisions and connector secrets are also encrypted at the application layer; other application data relies on the platform encryption alone.
- A new release is deployed as a new revision and promoted explicitly, so a rollback is a traffic change rather than a rebuild.
Backups & recovery
A backup nobody has restored is a hope, so restoring is the thing that gets rehearsed.
- Scheduled database backups plus point-in-time recovery, with delete protection on the production database.
- Restores are practised into a new database and validated before anything is migrated — production is never the drill target.
- Drills record the recovery point reached, the elapsed recovery time and any discrepancy found.
- Rehearsed at least quarterly, and again after a material schema or retention change.
Monitoring & containment
Small, specific controls beat a single big switch during an incident.
- Request logging, platform monitoring and provider status are checked together, not one at a time.
- Targeted kill switches — pause AI, pause sign-ups, enter maintenance mode — allow containment without a full outage.
- Health is verified from a real client and from more than one monitoring region before a switch is lifted.
- Server logs record the request, not the document: time, route, status and IP for reliability and abuse prevention.
LumenQube does not publish a contractual uptime commitment, and the Terms of Service provide the Service “as is”. The desktop app keeps working on your own files during an outage of our hosted services — that is the practical availability guarantee, and it is a property of the architecture rather than a number in a contract.
04 · EngineeringHow the software is built and shipped
Most security defects arrive through the build, not through the front door. These gates run on every change and on a schedule, and a red gate blocks the change rather than filing a note about it.
Checks on every change
Automated analysis in the pipeline, not a checklist somebody remembers.
- Static analysis over the codebase on every push and pull request, and weekly on a schedule.
- Secret scanning across full history, emitting a redacted report that names rule, file, line and commit.
- A type-check and an automated test suite gate every change before it can merge.
- Findings carry a time-bounded disposition — an accepted risk expires and comes back rather than becoming permanent.
Dependencies & supply chain
The parts you did not write are still parts you ship.
- Automated dependency updates run weekly; security advisories are raised separately so a fix is never held behind an unrelated major version.
- Third-party CI actions are pinned to immutable commit digests, not to moving tags.
- Container bases are pinned by digest and reviewed before they change.
- Installs in CI and in images resolve from the lockfile rather than from the latest published version.
Release integrity
What you download should be provably what we built.
- macOS builds are signed with an Apple Developer ID certificate, then notarized and stapled before release.
- Windows installers are signed with Microsoft Artifact Signing. If that signing configuration is incomplete, the release ships without a Windows installer rather than with an unsigned one.
- Linux packages are not code-signed. They ship with published SHA-256 checksums and a CycloneDX software bill of materials — that is file integrity and provenance, which is a different guarantee, and we would rather name it than blur it.
- The app checks for updates and can mark a release required when it carries a security or compatibility fix.
- Installers are distributed from our published release channel; a build from anywhere else is not ours.
The website itself
The page you are reading is part of the attack surface.
- A strict Content Security Policy with no
unsafe-inlinescripts — every inline script is pinned by SHA-256 digest. frame-ancestors 'none',object-src 'none'and a locked-down connect list.- HTTPS is enforced and insecure requests are upgraded.
- No third-party advertising or cross-site tracking scripts are loaded on any page.
05 · AccessWho can reach production, and on what terms
LumenQube is a small company, and pretending otherwise in a security document would be the least useful thing we could do. Access control here means a short list of named people with a narrow set of privileges — not a directory of roles nobody fills.
- Least privilege. Administrative access to production is limited to the people who operate the Service, using accounts protected by multi-factor authentication.
- No routine access to your content. Personnel do not read documents, Google data or connected-app content except where you give explicit permission for a specific support request, where access is necessary to investigate abuse or a security incident, or where the law requires it.
- Administrative actions are recorded. Operator actions in the admin console are attributable, and configuration changes to scaling, payment mode and feature switches are made there rather than by hand at the platform.
- Credentials are rotatable. Provider keys and connector secrets are held server-side and can be rotated without a client release; any credential exposed in an incident is rotated before the incident is closed.
- Subprocessors are chosen, not accumulated. Each provider in the published list receives only the data its feature needs, and adding one is a change to that list.
06 · MemoryWhat the assistant knows, and where each part of it is kept
The assistant draws on two separate stores with different locations and different lifecycles. They are described one at a time on purpose: a tidy three-tier diagram — local, synced, cloud — would misdescribe this, because the graph has no cloud tier at all and durable memory is not one store synced but two that never reconcile. The controls live in LumenAgent settings → Memory.
The context graph
Links between your own notes, tasks, meetings, events and people.
- This device only. A local database beside your documents. It is not synced to us and not backed up to us.
- Nothing is fetched to build it — it is derived from files you already have.
- Notes and tasks are treated as sensitive and stay out of the plain-text index entirely.
- The engine can be switched off, after which no context is assembled at all.
Durable memory
Facts the assistant saved because you told it something durable.
- Two stores, not one synced store. Up to 200 are kept on this computer; the mobile app reads a separate cloud set of up to 64. They do not reconcile, so they can genuinely differ.
- Credentials, API keys, card numbers, private keys and recovery phrases are screened out before anything is saved or synced.
- Switching memory off means the block is not built for a request at all.
What travels with a question
Two blocks, both readable in full before anything is sent.
- The context pack carries titles and how far apart things are — never file contents, bounded at 24 items and 4,000 characters.
- Objects you have excluded are removed before the pack is built, and are counted rather than silently dropped.
- An object encrypted to a keychain this machine does not hold cannot be read into the pack.
- The memory block rides the cached portion of the request rather than being re-sent with every question.
Erasure
Forget reaches five stores, and no cascade spans them — which is why it is a deliberate operation rather than a delete.
- The object, its links, the full-text index, the embeddings held in the app's working memory, and any durable memory naming it.
- The full-text index and the embeddings are each reached explicitly — a database cascade reaches neither.
- Every store is attempted independently, and the result names what it could not reach instead of reporting success.
- It does not reach copies you exported elsewhere, or a request already sent in an earlier conversation.
Want to see the exact text? The homepage prints both blocks verbatim, as the app assembles them.
See what gets sent →07 · ResidencyWhere data sits, and who else touches it
LumenQube Analytics Inc. is a Canadian company. Providers and connected services may process data in Canada, the United States and other countries where they operate. We do not currently offer a region-pinned deployment or in-region data residency. The exact processing location for a service requires current account/provider evidence.
- Application data — accounts, allowances, shared revisions, objects and logs — is handled by our hosting services under the configuration that applies to the deployed environment; no region-pinned option is offered.
- AI requests are processed by the provider selected for that feature. Provider/account terms and settings, retention and processing locations must be confirmed for that path.
- Transactional email is sent through Mailjet; account terms, subprocessors and processing locations require current evidence.
- Connector traffic goes to the service the user connected; processing location depends on that provider, service, account and request.
- A data-processing agreement, Standard Contractual Clauses, a UK Addendum, adequacy or another transfer mechanism applies only when confirmed for the specific provider, account and transfer; this page does not represent one as executed.
Providers and provider classes, their conditional purposes and the evidence boundaries for location and terms are published in Privacy Policy §12. For a current procurement schedule or provider question, email privacy@lumenqube.com.
08 · IncidentsWhat happens when something goes wrong
We run a written incident procedure rather than improvising. The order below is the order it is actually performed in, and the first step is deliberately not “fix it”.
- 1Name an owner, start the logOne person holds the incident, and everything observed goes into one timestamped record.
- 2Contain with the smallest safe controlPause AI, pause sign-ups, or enter maintenance mode — in preference to an emergency change nobody has reviewed.
- 3Preserve the evidenceRequest identifiers, revision, affected routes and accounts, provider event identifiers. Secrets, tokens and customer document contents are never pasted into the log.
- 4Recover deliberatelyRoll back the suspect release. For data loss, restore into a new database and validate before any migration.
- 5Verify from outsideHealth is confirmed from a real client and more than one monitoring region before a containment switch comes off.
- 6Close properlyRecord impact, detection, timeline, root cause and customer communications; rotate any exposed credential; and test the prevention control before declaring the incident closed.
Notifying you
If a security incident affects your personal information, we will notify affected users, and the relevant supervisory authorities, where applicable law requires it — including the timelines set by that law. Notification will describe what happened, what information was involved, what we have done, and what you should do. We will not delay a notification in order to make it read better.
09 · AssuranceCSA self-assessments, published with the gaps left visible.
LumenQube has been listed in the CSA STAR Registry since July 31, 2026, carrying both STAR Level 1 and STAR for AI Level 1. Level 1 is a provider self-assessment that CSA publishes — it is not an independent audit or a third-party certification.
Every answer we filed is public on the registry entry — 603 questions across CSA's Cloud Controls Matrix and AI Controls Matrix, including the ones still open. Read the entry →
STAR Level 1
Listed · July 31, 2026
- CAIQ v4.1 — 283 questions across the Cloud Controls Matrix.
- The published assessment separates LumenQube, customer and upstream-provider responsibilities.
- Open controls are recorded as open rather than left blank.
STAR for AI Level 1
Listed · July 31, 2026
- AI-CAIQ v1.1 — 320 questions on responsible-AI and AI security.
- LumenQube is assessed as an application provider using managed model APIs.
- We do not train a foundation model on customer content.
What Level 1 does and does not mean
- It is a public provider self-assessment, reviewed and published by CSA.
- It is not a penetration test, and it is not a guarantee.
- The workbooks include truthful No and not applicable answers, which is the point of publishing them.
Kept current, not filed and forgotten
- Both assessments are reviewed at least annually against the published registry date.
- And again after any material service, provider, legal or threat-model change.
- The registry entry is the version of record; this page summarizes it.
So that nobody has to infer it: we have not completed a SOC 2 examination, and we do not hold ISO 27001 certification. We have not commissioned a published third-party penetration test. If your procurement process requires one of those, tell us what you need and by when — we would rather scope it with you than let a badge be implied by silence.
10 · ReviewFor security reviewers and procurement
If you are evaluating LumenQube for an organization, start with the registry entry — it answers most standard questionnaires verbatim. For anything it does not cover, email security@lumenqube.com and say which framework you are working from.
| What you need | Where it is | How to get it |
|---|---|---|
| Filled security questionnaire | CSA CAIQ v4.1, 283 answers | Public on the registry entry |
| AI-specific assessment | CSA AI-CAIQ v1.1, 320 answers | Public on the same entry |
| Provider and service schedule | Provider or service, conditional purpose and current evidence boundary | Privacy Policy §12 |
| Proposed data-processing terms | Controller/processor allocation and transfer terms for review; no DPA or SCC is represented as executed | Email legal@lumenqube.com |
| Architecture & data-flow summary | What is sent, when, and to whom | Email security@lumenqube.com |
| Assessment package & scope | Current version, customer responsibilities | Request the package |
Three questions decide most rollouts, and all three have honest answers above: shared documents are not end-to-end encrypted (§02); there is no region-pinned residency option (§07); and our assurance is a published self-assessment rather than an audit (§09). If any of those is a blocker, say so early and we will tell you plainly whether it is on our roadmap.
11 · DisclosureReporting a vulnerability
If you have found a security issue, we want to hear about it before anyone else does. Email security@lumenqube.com with the affected product or URL, reproduction steps, impact, and any supporting evidence.
Responsible disclosure
Report it privately, and we will not come after you.
Email the report privately. We will triage it according to severity and available coverage, but we do not promise a fixed acknowledgement, assessment or resolution time. We do not currently run a paid bounty programme. If you want public credit after a fix is released, include that preference in your report.
In scope
- lumenqube.com, app.lumenqube.com and view.lumenqube.com
- The published desktop applications and the mobile app
- Authentication, authorization, sharing, publishing and connector flows
Out of scope
- Denial of service, volumetric or automated scanning traffic
- Social engineering of our people, our users or our providers
- Findings that require a compromised device or a physically present attacker
- Missing hardening headers with no demonstrated impact
Safe harbour. If you make a good-faith effort to follow this policy, we will not pursue or support legal action against you for your research. Please stay within scope, do not access, modify or destroy other people's data, do not degrade the service for others, use only test accounts you control, and give us a reasonable chance to fix the issue before disclosing it publicly.
12 · QuestionsSecurity, in plain language
Are shared documents end-to-end encrypted?
No. Shared and published documents are encrypted in transit and at rest, including application-layer encryption of stored revisions — but LumenQube manages the keys so authorized server processes can render and synchronize the content. That is encryption at rest, not end-to-end encryption, and we will not describe it as the latter.
When does a document leave my device?
Only when you use a feature that needs cloud processing: AI, sharing, web publishing, a connected service, or a support report with attachments. Ordinary local editing does not upload document contents at any point.
What is your CSA STAR status?
LumenQube is listed in the CSA STAR Registry and has been since July 31, 2026, carrying STAR Level 1 (CAIQ v4.1) and STAR for AI Level 1 (AI-CAIQ v1.1). Level 1 is a provider self-assessment that CSA publishes — it is not an independent audit, a third-party certification, or a penetration test. Every answer we filed is readable on the registry entry.
Do you train AI models on my content?
LumenQube does not use your content to train a generalized AI model as a product purpose. Content is sent only when you request an AI feature, to the selected processor or eligible fallback needed for that request. A provider's own data use, retention and permitted security or legal processing depend on the service and our account terms and settings. See Privacy Policy §7.
Can I revoke access to work I already shared?
Yes. Owners can change member roles, remove collaborators, revoke browser links, and rotate the document key after an access change. A copy somebody already downloaded is outside LumenQube's control — that is true of every system, and worth planning for.
Where is my data stored?
Providers and connected services may process data in Canada, the United States and other countries where they operate. LumenQube does not offer a region-pinned deployment or in-region data residency. The exact processing location for a service requires current account/provider evidence; see Privacy Policy §12.
Can I get a DPA, or have you fill in our questionnaire?
A proposed written agreement, including data-processing terms where applicable, may be requested from legal@lumenqube.com. No DPA, SCC or transfer mechanism applies unless authorized representatives execute or otherwise validly accept it. For questionnaires, start with the CSA registry entry and email security@lumenqube.com with anything it does not cover.
How do I make a privacy request?
Email privacy@lumenqube.com from your account address. Privacy Policy §18 explains the access, correction, deletion, portability, objection and restriction rights that may apply where you live.