The schema carries PERMISSIONS NONE, so Navigator's authorization lives above the database. SurrealDB does have an
opinion — every table carries a PERMISSIONS clause the engine evaluates per row against the authenticated session — so
adopting it forced a decision rather than inheriting one.
The decision is that authorization stays above the database. Every table says PERMISSIONS NONE out loud even though
that is also the engine's default, because an omitted clause and a deliberate one are otherwise indistinguishable, and a
test fails if a table ever lands without one. Be precise about what NONE buys: it denies every non-root session
outright, and root bypasses it — so the security property comes from the connection, and the clause is a fail-closed
backstop for a session that does not exist yet.
Mirroring the role-and-participation model into per-table PERMISSIONS FOR select expressions was the rejected
alternative, and the conflict check is why. That traversal walks from a proposed client across matters the requesting
person has no part in — which is exactly what imputed firm-wide conflict checking under Model Rule 1.10 means — so a
mirrored policy would need a carve-out at its first real query. Two languages that must agree is also the expensive
failure: a rule that drifts is either over-disclosure, a confidentiality breach, or under-disclosure, which in a
conflict check means a missed conflict. Neither shows up as an error.
What reopens it: the first surface that hands query power closer to a user — a folder read daemon, an MCP tool issuing
SurrealQL, a debugging console — does not get the root credential. It lands its own scoped non-root session and settles
that credential in each deployment's secrets.enc.yaml at the same time.