Knowledge-Base Search Tenant Scope Integrity Automation: One Clause That Switched Off the Only Guard

A scope filter that reads "if a specific value is provided, narrow to it" is a natural, common pattern — and it carries a quiet trap. Writing that same idea as "if the value is absent, skip the narrowing" instead of "if the value is absent, match only what has no owner" silently converts a legitimate case — a caller with no specific sub-scope — into a caller who sees literally everything, because an empty condition in a filter does not mean 'match nothing new,' it means 'stop filtering.' The two phrasings look almost identical in code and produce opposite security properties.

Centriu Synapse's AI assistant retrieves relevant knowledge-base content through a dedicated database function before generating a response, filtering the underlying chunks by organization and, where the calling context has one, by the specific tenant it belongs to. The function's scope predicate read: match chunks in the caller's organization, and match on tenant only if the caller's own tenant value is present — otherwise, skip the tenant condition entirely.

That second half is the defect. "Skip the condition" does not mean "match only tenant-less, organization-wide content," which is what a caller with no specific tenant is actually entitled to see — it means the database applies no tenant filter at all, and every chunk in the organization, regardless of which tenant it privately belongs to, satisfies the query. The caller this affects is not hypothetical or malformed: an organization-wide API credential, used in an organization that runs more than one active tenant, is a documented, ordinary shape of caller in this system — and every one of that shape's retrieval calls returned content it had no scope to see.

Confirmed directly from the fix's own investigation why nothing else caught this: the retrieval function is declared to run with the INVOKER's privilege in name, but the backend always calls it using an elevated, row-level-security-bypassing database role — meaning the table's own access policy never gets a chance to apply during this specific call path. That policy, in any case, only verifies organization membership, with no clause about tenant at all. The predicate inside the function itself was therefore not a second, defense-in-depth layer behind the table's own policy — it was the only guard standing between one tenant's private knowledge base and another's, for this entire code path.

The proof, both of the leak and of the fix, came from a single four-probe measurement rather than a single before/after comparison. A caller correctly scoped to one specific tenant, both before and after the fix, received exactly that tenant's own matching content — unaffected, confirming the fix does not narrow a case that was already correct. A caller scoped to a different specific tenant showed the same: correct and unaffected on both sides. A caller from an entirely different organization received nothing, in both measurements — organization-level separation was never the broken part, and remained intact throughout. Only the fourth case — the organization-wide caller — showed a difference: every tenant's content, before; none of a specific tenant's private content, after, correctly leaving only genuinely organization-wide material (content with no specific tenant owner) reachable. The count of chunks actually stored in the underlying table was identical in both measurements, confirming the fix changed what a QUERY is allowed to return, not what data exists or how much of it there is.

The fix itself is a single removed clause: the predicate no longer treats an absent tenant value as a reason to stop filtering — it now treats it as a reason to match only chunks that are themselves genuinely organization-wide, the behavior an organization-wide caller was always supposed to get.

An organization runs Centriu Synapse for several of its own active tenants at once, using one organization-wide API credential for a shared integration. Before the fix, a knowledge-base query made with that credential returns matching content from every one of those tenants — including material that tenant never authorized the organization-wide integration to see. After the fix, the identical query returns only the organization's own genuinely shared, tenant-less knowledge base content — a specific tenant's private material stays private unless the caller is scoped to that exact tenant.

Centriu Synapse's knowledge-base retrieval function now enforces tenant scope for every caller shape, including the organization-wide case that previously disabled the filter entirely — proven by a four-probe measurement that confirms the fix narrows only the case that was actually leaking, with organization-level isolation and correctly-scoped tenant callers both unaffected.

This automation governs the internal scope-filtering logic of Centriu Synapse's own knowledge-base retrieval function — it does not change what content an organization chooses to add to its knowledge base, does not add a new access-control layer a customer configures directly, and does not affect organization-level isolation, which was already correctly enforced and remains unchanged.

Relying on a single, well-written filter is efficient and, for as long as it stays correctly written, entirely sufficient — the risk is not the pattern itself but the absence of any independent check confirming it stays correct when a call path bypasses the layer (row-level security) that would ordinarily catch a filter written by mistake to match too much. Where a function runs with elevated privilege specifically because it needs to bypass that layer, its own internal predicate stops being one guard among several and becomes the only one — worth treating with the scrutiny, and the boundary-case testing, that fact implies.