Skip to main content
luminarforge.
  • Real people & productsWritingTemplatesIllustrationsPublishingPlanning
  • For agencies
  • For one business
  • Examples
  • Pricing
Log in Try it free
The audit sheet — trust & security
Page reviewed
07 Sep 26

Trust, itemised.

Six defence layers, a four-link isolation chain, and the numbers behind them — each line dated, and each line stamped with where the proof lives: in our code, or in the platform accounts that front it. Your clients’ brands, voices and faces live in this system; this page is the inspection record.

On 7 September 2026 we re-traced every claim on this page to the code behind it. Nine were wrong. All nine are corrected below — and three we fixed in the product rather than softening the sentence.

Security contact — security@luminarworks.com · answered by the people who build it

Code

Verifiable in the codebase. The mechanism exists as reviewable source — middleware, migrations, services — and the claim was re-checked against it on the review date.

Infra

Configured in the platform accounts — Cloudflare, Render, Supabase. Real, reviewed on the stamp date, but not visible in source code — so we say so instead of blurring the two.

Defence in depth — six audited lines

The audit sheet.

A request crosses six layers between the internet and a client’s data. Each line below is a real mechanism with a review date — not a diagram of intentions.

LineLayerWhat actually runsProof lives
01Reviewed
07 Sep 26
EdgeCloudflare The API sits behind Cloudflare’s edge network — our host’s, not an account we control; DDoS absorption comes with the territory. The website itself is served from Vercel’s. Turnstile challenges sit on the signup, password-reset and login forms. Infra
02Reviewed
07 Sep 26
TransportTLS Encrypted in transit end-to-end, with HSTS enforced from our own middleware — the strict-transport header is ours; the cipher negotiation is the platforms’. Infra
03Reviewed
07 Sep 26
ApplicationExpress middleware Helmet security headers, HPP, strict CORS, and rate limiting — a global 100 requests/minute throttle per IP, plus per-user fair scheduling so one tenant’s burst can’t starve another. Code
04Reviewed
07 Sep 26
DataPostgres RLS Browser credentials can read six tables and write nothing at all. Postgres policies fence one account from another; the client-level check that fences one of your clients from the next is made by the server, on every request. So there is exactly one route to client data, and it is the one that checks. Code
05Reviewed
07 Sep 26
SecretsAES-256-GCM Third-party API keys and OAuth tokens are encrypted at rest with AES-256-GCM — fresh IV per encryption, auth-tag verified on decrypt — and only decrypted in memory at the moment of use. Never logged, never cached. Code
06Reviewed
07 Sep 26
InputValidation Zod schemas across the API; uploads checked by MIME type, magic bytes, and size — SVGs are sanitised before storage. Code
Client isolation — the chain of custody

Four links between any user and any row.

Agencies run many clients in one account. The isolation model is the product’s spine: there is exactly one route to client data, and it is the one that checks. The credential your browser holds cannot reach it — it can read six tables and write nothing at all.

Link 01

Tenant

Your agency’s account — the billing and plan boundary. Every JWT carries its tenant claim.

Link 02

Workspace

One workspace per client. Brand assets, voice, knowledge base, people and products are workspace-scoped — never pooled.

Link 03

Role

Owner → Admin → Multi-Account Manager → Member → Viewer. Every request re-checks the caller’s role in middleware.

Link 04

Row

Postgres RLS filters by account, at the database level, and file storage policies check the workspace too. The client check on content is the server’s, on every request.

The order matters: by the time a query reaches the data, three layers have already said yes — and the fourth refuses the browser outright, so there is no way round the first three.

Compliance — the working parts
PillarReviewed 07 Sep 26

GDPR-ready, mechanically

Full data export on demand — streamed archive, API keys redacted, link delivered by email. Account deletion with a 72-hour grace period and one-click cancel, then a cascade across 34 tables in FK-safe order plus the storage buckets. Ready means built, not aspirational — and we don’t claim a certification we don’t hold.

PillarReviewed 07 Aug 26

Billing without card data

Polar is our Merchant of Record — payments, VAT, sales tax and regional regimes are collected and remitted by Polar as an independent controller. Card numbers never touch our systems.

PillarReviewed 07 Sep 26

Auditable by default

19 audited action types — workspaces, members and roles, settings, API keys, billing and admin actions — captured to a dual-persistence trail: structured logs plus an audit table a database trigger refuses to let anything rewrite, our own server included. Deleting an account cascades its trail away with it — the erasure the privacy policy promises. Sign-in events are not in this trail — logins, password changes and MFA are handled by our authentication platform and recorded there.

PillarReviewed 07 Sep 26

Data minimisation

Application logs mask email addresses — m***@example.com, enough to trace a support case, not enough to harvest — and redact passwords, API keys and bearer tokens outright. Error telemetry scrubs again on the way out, pattern-matching addresses and secrets out of every event it sends. Transaction tracing samples at 10%.

Under load — the operational numbers
3.

Concurrent pipeline runs per tenant — fair scheduling; no tenant can starve another.

11.

Alert rules with cooldown windows — circuit-breaker trips, 5xx error spikes and RLS violations page a human.

100%

Of errors sampled to telemetry, not a fraction — scrubbed first. Two expected classes are filtered out: rejected cross-origin requests, and rate-limit responses.

0.

Card numbers stored, ever — Polar is Merchant of Record; payment details never touch our systems.

Every upstream AI provider sits behind a circuit breaker — a provider outage fails over, queues, or returns a clean error · numbers re-checked against source 07 Sep 26

Likeness rights — asked plainly

Real faces get their own section.

The AI Imagery feature can put a real person — a client’s founder, a team member — into generated scenes. That deserves more than a marketing line, so here is exactly how consent, storage and deletion work.

What does “consent on file” actually mean?

A person cannot be added without an explicit consent confirmation — the create request is rejected without it, and the system records who confirmed and when, permanently attached to the person’s record. Said plainly: it is an auditable record of the confirmation, not a stored legal release. The agency remains responsible for holding the person’s actual permission; the platform makes the moment auditable.

Can a person be removed?

Two levels. Pause stops the person appearing in any future generation but keeps their record so previously created artwork still resolves. Delete (admin-level) removes the person’s record and their reference photos from both the database and file storage. Individual photos can also be deleted one at a time.

Do reference photos ever leave the workspace?

They are stored workspace-scoped under row-level security — no other client, and no other tenant, can reach them. At generation time, reference photos are transmitted to the AI image provider to render the scene, under provider terms that exclude training on customer content. We won’t say “they never leave” — that would be false. They leave for exactly one purpose, and they are not kept.

Whose photos can be uploaded?

People who have given the agency their permission — that is what the consent confirmation asks you to affirm, per person, before any photo is accepted. Five reference photos per person, angle-slotted, capped. We test the feature on our own founder’s face — the standard is: comfortable enough to use it on ourselves.

Said plainly — what we don’t claim
The absences, stated
  • No SOC 2 or ISO 27001 certification. We don’t hold one and won’t imply otherwise. If that changes, the changelog says when.
  • No uptime-percentage theatre. We publish mechanisms — circuit breakers, alerting, fair scheduling — not a decorative number we haven’t earned the history to quote.
  • MFA is available on every account, not enforced on yours. TOTP two-factor is built in and one screen away; our own admin access requires it. Yours is your policy call.
  • No enterprise SSO yet. Accounts authenticate with email/password, magic link, Google or LinkedIn — SAML/OIDC single sign-on doesn’t exist here today, and this page won’t pretend it does.
Privacy principles — four sentences
We do not train models on your content. Your data is excluded from AI-provider training under their standard API terms for paid accounts, plus a data-processing agreement with each. Restated from the privacy policy, qualifier included
You own your data. Export anything, anytime — the full-archive export is self-serve.
We do not sell, rent, or share customer data. Subprocessors are named in the privacy policy.
Nothing is pooled across tenants. Brand assets, voice DNA, knowledge bases, people and master prompts are workspace-scoped.

The sheet is signed

Audit us before you trust us.

Bring this page to your security review — or write to security@luminarworks.com and ask the awkward questions directly. The answers come from the people who wrote the middleware.

Start with 5,000 free credits Read the privacy policy

No card · No trial countdown · No per-client fees

luminarforge.

Product

  • Real people & products
  • Writing
  • Templates
  • Illustrations
  • Publishing
  • Planning

Who it's for

  • For agencies
  • For one business
  • Examples
  • Compare
  • vs Canva
  • Pricing

Company

  • Trust & security
  • Changelog
  • Contact
  • Log in

Legal

  • Terms
  • Privacy
  • Cookies
  • Refunds

Publishes to LinkedIn profiles and company pages. Instagram, Facebook and X: copy-and-paste.

© 2026 Luminar Works