By KYN AI Advisory Team — AI implementation specialists, Singapore
Any website with a login, a client portal or a database holding more than one customer's records is multi-tenant. The question is whether the separation between customers is enforced by the database or hoped for by the application. These are the questions to ask before the first record is stored.
What is row-level tenant isolation?
In a multi-tenant database, every customer's rows sit in the same tables. Isolation is what stops customer A's page from reading customer B's rows.
Application-level isolation adds a filter in code: every query includes "where tenant equals the current tenant". It works until one developer forgets the filter on one query, and that query becomes a data leak.
Row-level isolation moves the rule into the database. Each table carries a tenant identifier, and the database enforces a policy that a session can only see rows matching its tenant. A query with no filter returns only that tenant's rows. A bug in a page cannot read another client's data because the database will not return it.
From our own builds: every client system with shared tables uses row-level policies keyed on the tenant identifier. The application sets the tenant once per request, and the database does the rest.
Ask your developer: if a query forgets the tenant filter, what happens? The right answer is "nothing is returned".
Who can reach the database and how?
Access to the database is a list of names, not a shared password.
- One role per person and one per service, each with the permissions its job needs. A reporting service reads; it does not write.
- No shared logins. A shared login cannot be revoked for one person and cannot be attributed in a log.
- Access through a proxy or a private network, not a public address. The database should not be reachable from the internet at all.
- Every connection attributable: the log shows which role ran which query.
- Revocation in one place. When a person leaves, their role is disabled and nothing else needs to change.
From our own builds: database access on client systems runs through a proxy with named roles, and the handover lists every role and who holds it.
What should every API route check before it runs?
The website's API is the door between the browser and the database. Every route should check who is knocking before doing anything.
From our own builds, the standard is two credentials on every route: a key that identifies the application and an actor that identifies the person or service making the request. Both are checked in middleware, before any route handler runs, so a new route cannot be deployed without the check.
- Missing or wrong key: rejected before the handler.
- Missing actor: rejected before the handler.
- Actor without permission for the tenant: rejected.
- Every rejection logged with the route and the reason.
Ask your developer: show me the middleware. If the check lives inside each route instead, the next route will forget it.
How are secrets rotated and tracked?
Secrets are the API keys, database passwords, OAuth client secrets and signing keys the site depends on. Each one expires or should.
- Store them in the host's secret manager, never in the repository or a shared document.
- Give each secret an expiry date and put that date on a calendar someone reads. From our own builds, an identity provider's client secret has its expiry recorded with a reminder months ahead, because the day it lapses, logins stop.
- Rotate on a schedule and on any departure of someone who had access.
- Keep a list of which service uses which secret, so a rotation does not break an integration nobody remembered.
What should the handover document include?
The handover is what makes the system yours rather than your developer's. It should list:
- Every environment: production, staging, local, and where each runs.
- Every account: registrar, DNS, hosting, database, email, analytics, with the owner's name.
- Every role with database access and what it can do.
- Every secret, where it is stored, when it expires, and which service uses it.
- The isolation model: which tables carry a tenant identifier and which policies enforce it.
- The API protection: what middleware checks and where the log goes.
- Backups: schedule, retention, and the date of the last tested restore.
If a proposal for a website with a database does not cover these, security is being left to chance. The questions above take an hour to answer and years to regret. For a build where the isolation, the access model and the middleware are part of the website work from the start, see website security built in from the start.
Frequently asked questions
Does a brochure website with a contact form need this?
A contact form that stores submissions in a database holds personal data. It needs named access and backups. It does not need tenant isolation unless the database serves more than one business.
Is a separate database per customer safer than row-level isolation?
It is simpler to reason about and more expensive to run and maintain. Row-level isolation enforced by the database gives the same protection for most SME systems at a fraction of the operating cost.
How do I verify my developer's claims?
Ask for three things in writing: the policy definition on one table, the middleware file, and the list of database roles. Each is a few lines and either exists or does not.
Checked October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.