Cross-Tenant Portfolio Mixing Automation: Two Organizations' Data, One Unfiltered Query
Row-level security answers 'is this allowed,' not 'is this the row this screen is scoped to'
A database's row-level security policy exists to answer one specific, foundational question correctly: given who is asking, is this particular row something they are allowed to see at all? That question, answered correctly, is necessary but not sufficient for a screen that is additionally meant to represent exactly ONE specific context — a screen labeled with a single organization's name, showing that organization's portfolio, is making an implicit promise that everything on it belongs to that organization specifically, not merely that everything on it is something the viewer happens to be allowed to see. When the second, narrower promise is left entirely to the first, broader policy to enforce — rather than an explicit filter matching the screen's own specific context — the two only agree by coincidence, for exactly as long as the viewing person's own permissions happen to be narrow enough that the difference never becomes visible.
How the underlying problem shows up before you fix it
A screen or feature is scoped, by its own design and labeling, to ONE specific entity (an organization, an account, a client) — but the underlying query fetching its data applies no explicit filter narrowing the read to that one specific entity, relying instead on a broader access-control layer to implicitly produce the correct narrower result.
Row-level security correctly grants read access across EVERY entity a person is legitimately a member of — a genuinely correct policy for the broader question of what a person may see — while a specific screen's own narrower promise (showing only ONE of those entities at a time) depends on something else entirely to enforce, and nothing else does.
The defect is completely invisible for the majority of users (anyone belonging to exactly one entity, where the broad and narrow questions happen to produce an identical answer) and becomes visible only for the specific subset of users whose own legitimate access genuinely spans more than one entity — precisely the users least likely to be included in an ordinary single-account test pass.
Two logically separate concerns (which rows is this person allowed to see at all, and which ONE of those the current screen should actually represent) are collapsed into a single control (a database access policy) that was designed, correctly, to answer only the first question.
A defect of this shape produces no error message, no failed request, and no visibly broken screen — everything renders successfully and looks completely normal, with the only symptom being the wrong DATA appearing correctly formatted inside a screen that looks exactly as intended.
Why relying on row-level security alone feels sufficient until a multi-organization user tests it
Row-level security is a genuinely strong, foundational control, and it is easy — reasonably so, during ordinary development and testing with a single-organization account — to treat its grant as the complete answer to "is this query correctly scoped," since for that single-organization case, it functionally is. The gap only becomes visible for an account whose real, legitimate access spans more than one organization, which is both a less common testing scenario and, not coincidentally, exactly the scenario Helix's own product exists to serve (an agency managing multiple client accounts through one team). The narrower the population of accounts that can reveal a given defect, the more likely ordinary testing simply never happens to include one.
How Centriu Helix closed the gap between what a person may see and what a screen should show
A broader production audit of Centriu Helix's twelve AI feature areas found that the code responsible for fetching AI analysis subjects (the specific clients or accounts a feature analyzes) and generated reports applied no explicit filter narrowing that read to the one specific organization a given screen was actually meant to represent. Instead, the fetch relied entirely on the database's own row-level security policy — a policy that correctly, and by design, grants read access to every row belonging to any organization the signed-in person is a genuine member of.
For the overwhelming majority of Helix's users — anyone belonging to exactly one organization — this distinction produces no visible difference: the broader question (what am I allowed to see) and the narrower one (what should THIS screen show me) happen to have an identical answer. The defect activates specifically for a person genuinely affiliated with more than one organization, such as an agency team member responsible for covering more than one client's account. For that person, row-level security correctly permits reading analysis subjects and reports from every organization they belong to — and with no further filter narrowing a specific screen's own query down to the one organization it was meant to represent, both (or more) organizations' data could appear blended together inside what was designed and labeled as a single, cleanly scoped portfolio view. A report meant to represent one client's specific portfolio could, in principle, surface analysis or figures belonging to a different client entirely, inside the same screen.
The fix adds the missing, explicit organization filter directly to the underlying queries fetching both analysis subjects and generated reports, so that a screen scoped to a specific organization reads only that organization's own rows — regardless of how many additional organizations the viewing person's own broader membership might legitimately include. Row-level security continues to correctly answer its own foundational question (is this person allowed to see this data at all); the added filter now separately, explicitly answers the narrower one a specific screen actually needs answered (is this the ONE organization this screen represents).
What is actually built today
Centriu Helix's queries fetching AI analysis subjects and generated reports now apply an explicit organization filter, scoping every screen's data read to the one specific organization it is meant to represent.
Row-level security continues to enforce the broader, foundational access question (is this person a legitimate member of the organization this row belongs to) exactly as it did before this fix.
A person legitimately affiliated with more than one organization now sees each organization's own portfolio and reports correctly separated, with no blending across organizational boundaries within a single scoped screen.
The fix applies uniformly across all twelve of Helix's AI feature areas, closing the identical unfiltered-query pattern wherever it existed rather than patching one specific feature in isolation.
This finding and fix were confirmed against Centriu Helix's real production database as part of the broader audit that also restored the module's complete AI outage and closed its CI coverage gap.
Two accounts, two very different experiences of the identical screen (illustrative framing of the actual confirmed mechanism)
Before the fix, a person belonging to exactly one organization would open any Helix feature's portfolio screen and see only that organization's own data — the defect invisible, because the broad and narrow questions happened to agree. A person genuinely affiliated with two organizations, opening the identical screen scoped to one of them, could instead see analysis subjects and reports from BOTH organizations blended together, with nothing on screen indicating anything was wrong. After the fix, both kinds of account see only the one organization the screen is actually scoped to, regardless of how many organizations either account's own broader membership includes.
What changes operationally
Centriu Helix's AI feature screens now correctly scope every data read to the one specific organization each screen represents, closing a gap where a person legitimately affiliated with more than one organization could see multiple organizations' analysis subjects and reports blended together inside what was meant to be a single, cleanly scoped portfolio view — with row-level security continuing, separately, to correctly govern who may access data at all.
When this is not the right fit
This automation covers specifically how Helix's queries scope a screen's data to one organization — it does not change or replace row-level security's own, separate, correctly-functioning enforcement of who may access an organization's data at all. It is also distinct from this pillar's companion pages on the same production audit's complete AI outage finding and mislabeled-KPI finding, both independently real, separately caused mechanisms discovered during the same broader investigation.
One broad access-control layer vs. a broad layer plus a narrow, explicit filter
Trusting row-level security alone to produce a correctly narrow result for every specific screen is simpler to build and reason about, and it is entirely sufficient for the common case of a person belonging to exactly one organization. The moment a real user's own legitimate access genuinely spans more than one organization — which this specific product is explicitly built to support — that same simplicity stops producing the narrower result any specific screen actually needs. Adding an explicit filter matching a screen's own specific scope, on top of (never instead of) row-level security's own broader access check, is what correctly answers both the broad question and the narrow one, rather than assuming the broad answer happens to satisfy the narrow requirement.
Related systems
Main system: Centriu Helix.
What it does NOT do
- Does not change or weaken Centriu Helix's row-level security policy itself — that policy continues to correctly govern who may access which organization's data at all; this fix adds a separate, narrower filter on top of it for screen-level scoping.
- Does not affect any account belonging to exactly one organization — the defect this fix closes was invisible for that case, since the broad and narrow questions already produced an identical answer.
- Does not overlap with this pillar's separate companion pages on the same production audit's complete AI outage finding or its mislabeled-KPI finding — those are independently distinct mechanisms found during the same broader investigation.
- Does not retroactively identify or notify anyone about a specific instance where cross-organization data may have been viewed before this fix — the fix closes the underlying query gap going forward; a team needing a specific historical exposure assessment would need a dedicated review.
- Does not change what data any individual AI report or analysis subject actually contains — this fix corrects only which organization's data a given screen's query is scoped to read.
Security and governance
Centriu Helix's AI feature queries now apply an explicit organization filter scoping every screen's data read to the one organization it represents, closing a gap where a person legitimately affiliated with more than one organization could see multiple organizations' analysis subjects and reports blended together — with row-level security continuing to separately, correctly enforce who may access an organization's data at all. Full detail on access control, tenancy isolation, and audit trails lives at /governanca and /iso.
Pricing and contracting
Available by monthly subscription, with tiered plans. Values and terms come from the official pricing table at /precos (Centriu's central source — never restated here).
Frequently asked questions
Was this a row-level security failure?
No — row-level security correctly performed its own job throughout: granting access to every organization a person is a genuine member of. The gap was a separate, narrower filter that specific screens needed and did not have, to scope their own data read to just ONE of those organizations.
Which users were actually affected by this defect?
Specifically, people legitimately affiliated with more than one organization in Centriu Helix — for example, an agency team member covering more than one client's account. A person belonging to exactly one organization never saw any difference.
How was this defect found if it produces no visible error?
Through a broader production audit — this class of defect (correct-looking output built from an incorrectly-scoped query) produces no error message or broken screen, so it required deliberately testing the specific case of a multi-organization account rather than relying on any error report.
Does this fix change how row-level security works in Centriu Helix?
No — row-level security's own policy is unchanged and continues to correctly answer its own question (is this person allowed to see this row at all). This fix adds a separate, explicit filter answering a narrower, additional question specific to how each screen scopes its own display.
Does this affect all of Helix's AI features, or just one?
The unfiltered-query pattern existed across all twelve of Helix's AI feature areas and was closed uniformly across all of them in the same fix, rather than patched in only the one feature where it was first noticed.
What does Centriu Helix cost?
It is sold by subscription with a published starting price — exact current values are on the central pricing page.
See how Centriu Helix keeps every organization's portfolio genuinely separate
Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.