A two-part model. Ownership is a constant in source code — one person, permanent, unreachable by any config value. Everyone else who works on the platform is staff: a row with a role, an access status and an audit trail, managed from the platform team screen. Routes ask for a capability, never for a role and never for an identity.
Also called: vendor access · who can see my data · platform staff · support access
- 1The owner is resolved from source before any database call, so no outage or bad migration can lock him out.
- 2Staff are matched by any email on their account, or by their linked identity id once they've signed in.
- 3Only 'active' grants anything: 'listed' is a directory entry, 'revoked' is a former employee whose row is kept deliberately.
- 4Roles map to capabilities in one table: view the console, view accounts, manage accounts, enter accounts, view revenue, manage signups, work bugs, run the sales panel, manage staff, manage settings.
- 5Every grant, change and revocation is appended to a staff audit table.
- 6A database failure resolves to no access — never to a grant.
This module exists because of a specific July incident, and it says so at length. The owner list used to include an environment variable, and that variable contained a tenant owner's address — so 'every power above was therefore held by a customer, over every other customer: [they] could open [another builder's] account, change their plan, read their notes, and received an emailed copy of every bug report filed anywhere on the platform, screenshots included.' The analysis is the valuable part: 'Nothing was misconfigured by accident in the ordinary sense — the value was correct back when [he] WAS the product's only user… It stopped being correct the moment a second tenant existed, and no code noticed, because a config value that silently widens an authorization boundary produces no error and no log.' The design conclusion follows: 'ownership is now HARDCODED ONLY… That is a deliberate loss of flexibility.'
- A single configuration value silently widened an authorization boundary across every customer.
- Forty route handlers each held their own copy of the same access check.
- There was no record of who had vendor-side access, at what level, or when it changed.
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 →