Ownership can't be granted by configuration

The one account that can reach every customer is a constant in source, and any leftover environment value that used to grant it is now inert and reported as ignored.

What it is

A module exporting a single frozen owner address, checked before any database access. It reads no environment variable by design. A separate function lists any addresses still present in the old environment variable so a startup check can shout about them rather than leave someone believing an address grants access when it does not. Bug-report recipients are kept as their own list so an ops-access change can never quietly become a data-disclosure change.

Also called: owner email env var · hardcoded owner · who owns the platform

See it
Ownership can't be granted by configuration
Won
56%
Avg cycle
20d
Pipeline
$492k
JanSep
A code excerpt of the frozen owner constant next to a startup diagnostic listing ignored environment entries. src/lib/platformOwners.ts. Sample data — no customer information appears here.
How it works
  1. 1One constant defines the owner; the exported list is frozen at module load because middleware runs it on every request.
  2. 2getPlatformOwnerEmails() and isPlatformOwnerEmail() are safe to call from the edge runtime.
  3. 3isProtectedPlatformIdentity() is called by every staff-management path so 'remove the owner' fails at the door in the API, the UI and the database trigger.
  4. 4ignoredOwnerEnvEntries() surfaces stale environment addresses as diagnostics only — never as an input to an authorization decision.
  5. 5getBugAlertEmails() is a deliberately separate list from ownership.
Why we built it

The reasoning is written as doctrine: 'Ownership isn't a permission level that happens to be at the top of the scale — it's the floor under the scale.' The split between source and database is stated as the whole design: 'the account that can never be locked out is a constant in source, and everything that needs to change day to day changes in the database where it can be audited.' The separated bug-alert list carries its own justification: 'A bug report carries another tenant's name, the reporter's identity, their page, their words and their screenshots. Deriving that recipient list from the same function that answers who may administer the platform meant one loose config entry did two unrelated things at once, and the visible symptom (a customer getting bug emails) was the least serious of them.'

The problem
  • An environment variable could widen the highest authorization boundary with no error and no log.
  • One config value simultaneously controlled admin access and who received customers' bug reports with screenshots.
  • Removing the owner by accident would lock the platform's only permanent account out.
Sound familiar?
What you get
The top-level boundary can only change through code review and a deploy.
Stale configuration is reported loudly instead of being silently trusted.
Operational email recipients and administrative access are separate decisions.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →