How Lumee keeps your data yours

A number Lumee gives you is a number you make a decision on. That only works if you can trust where it came from and who else could see it. Here is how we earn that.

One project per client, no exceptions

Your data lives in a Google Cloud project that belongs to your business and holds nobody else's data. Lumee runs as a dedicated service inside that project with its own identity, and that identity can read only the datasets we have explicitly approved for you. There is no shared database, no shared service account, and no shared data path between clients. This is how the system is built, not a setting someone remembers to check.

Read-only, structurally

Lumee reads from your systems. It cannot write to them. When Lumee queries your warehouse it accepts a single SELECT statement, checks every table it touches against your approved list before running it, and caps how much data one question can scan. A query that tries to reach anything outside your approved datasets is refused, and we test that refusal with adversarial cases on the deployment gate.

Your credentials, handled carefully

You connect a platform like QuickBooks or Shopify through that platform's own sign-in and consent screen. We never see your password. The token the platform issues is stored encrypted in Google Cloud Secret Manager, one secret per client per platform, and only the process that synchronises your data can read it. We refresh tokens before they expire rather than waiting for a failure, we store the rotated token immediately, and we alert ourselves when a refresh fails so a dead connection surfaces to us before it surfaces to you as a stale number. Our own application credentials, including the client ID and secret for each platform, live in Secret Manager too. Nothing is in code, in a container image, or in a log.

No long-lived keys anywhere

Every workload authenticates using Google Cloud's own identity system. There are no downloadable service account keys, and there never have been. Our repository history is scanned for secrets on every change.

What we log, and what we never log

We record who asked a question, when, which tables were read, and how much data was scanned. We record the question text and the query, because that is how we find out where Lumee gets things wrong. A copy of that question and query text is kept centrally at Each Ember, and today it names your business and the person who asked. We never log the rows a query returned. Webhook payloads from platforms are verified and processed but their raw bodies are not written to logs.

Encryption

In transit, TLS everywhere. At rest, Google Cloud's default encryption on BigQuery, Cloud Storage, Secret Manager, and Cloud Logging.

Excluding what we do not need

For the platforms on our connector surface (QuickBooks Online, Shopify, Amazon Selling Partner, Square) we request the narrowest access that answers the questions you actually ask, and we exclude end-customer personal information. Where a platform sends a field we have not asked for, we drop it at the boundary before it is stored, and we verify that by inspecting real payloads, not by assuming.

Deleting when you say so

Disconnecting a platform revokes our access at that platform, removes that platform's data from your project, and destroys the stored credential. Ending the engagement removes everything. The purge runs inside your project under your project's own identity. Our central systems can signal it but cannot perform it.

Change control

Every deployment is gated on an automated evaluation suite that includes cross-tenant probes, prompt-injection attempts, and off-allowlist queries run against the live gateway. A build that fails certification does not ship on that gate. An operator can override the gate deliberately, and doing so writes an UNCERTIFIED record naming that deployment, which is the record we show you. Deployment history and audit logs are retained for review.

Incidents

We have had no security incident requiring notification to a client or a regulator. If one occurs, we will notify affected clients promptly, in plain language, with what happened, what data was involved, and what we are doing about it. Report a suspected issue to info@eachember.com.

Where we are on SOC 2

We are building toward SOC 2 from day one: controls and an evidence trail first, an audit when a client engagement calls for it. That is a SOC 2-ready posture, pre-audit by design. We do not claim to be SOC 2 compliant, because nothing is compliant without a report.

Who to ask

info@eachember.com. A person reads it.