Isolation you can check,not isolation you are promised
Multi-tenancy is usually a review problem: every new query is one missed WHERE clause away from a leak, and the defence is that somebody would have caught it. DjiniousMap moves the boundary into the two databases, where a wrong query returns nothing rather than returning somebody else's rows.
Five places the boundary is enforced, none of them a request handler
SurrealDB — permissions per verb
SCHEMAFULL · PERMISSIONSEvery table is SCHEMAFULL and carries a PERMISSIONS clause for each verb, evaluated against the record the connection signed in as. A denied read returns nothing. A denied write returns nothing either — which is why every write checks that a row came back rather than assuming it landed.
PostgreSQL — row-level security with FORCE
nosuperuser · nobypassrlsFeature tables are governed by row-level security declared FORCE, so the policies apply to the owning role as well. That role is created nosuperuser and nobypassrls: there is no principal in the database that can read past a policy, including the one that created the table.
The organization is set before the first statement
SET LOCAL, per transactionEvery request opens its transaction through a helper that sets the organization before any statement runs; the policies read that setting. A request that resolved no organization cannot open a transaction at all, so 'forgot to scope it' is not a reachable state.
Materialization is guarded by the database too
security definer, caller's RLSThe function that creates a dataset's feature table is security definer, and its first act is to check the dataset exists — a check that runs under the caller's own row-level security. A tenant asking to materialize another tenant's dataset sees no row and is refused by the database, not by a handler.
The suite derives its expectations from the grants
isolation testsThe cross-tenant test suite walks both stores and builds its expectations from the grants and policies it finds, rather than from a list somebody maintains. A table added without a policy fails the walk instead of passing because nobody remembered to add a case.
An append-only audit log, and a retention sweep that is required
Every mutation lands in an append-only audit log on its way past. Append-only means it grows without bound, so retention is not optional housekeeping: the maintenance command that sweeps expired audit events and dead sessions is meant to be scheduled, and the documentation says so rather than leaving it to be discovered.
- Append-only audit events, written on the mutation path rather than reconstructed after the fact
- A scheduled maintenance sweep for audit retention and session expiry
- A reconcile command that enumerates both stores and exits non-zero when the projected rows disagree
- Operator endpoints — /ready, /version, /metrics — on the provider interface
A session cookie, and nothing else
- Credential
- Argon2id. The password is verified in the database through a record access whose SIGNIN clause decides which single record the caller becomes.
- Session
- A 256-bit random token in an HttpOnly cookie. Only its SHA-256 hash is stored, so the session table is not a list of live credentials.
- Headers
- Never consulted for identity. A caller cannot claim an organization by asking for one.
- Development
- No stub and no override. A production boot needs no extra configuration to be safe, because there is no unsafe mode to turn off.
- Federation
- Login credentials federate to the shared Djinious core, so an operator manages one identity rather than one per application.
Bring your security review
The parts of this that matter are checkable: the policies, the roles, the isolation suite. A technical demo can go straight to them.