Route Guard Decorative Full-Access Automation: A Gate That Checked ID and Waved Everyone Through

A route guard component that runs on every protected screen looks, from the outside, exactly like a working access-control system: it renders, it consults a permission source, it decides what to show. Whether it actually protects anything depends entirely on what that permission source contains. A guard that consults a genuinely empty or universally-permissive rulebook is not a weaker version of access control — it is the visual appearance of access control with none of its substance, and the two are indistinguishable to anyone reading the screen without inspecting the code behind it.

Building a permission-checking hook ahead of the real, centralized access system it is meant to eventually read from is a reasonable way to unblock UI development without waiting on a larger, cross-cutting piece of infrastructure — and documenting that choice explicitly, with a stated plan for when the real version will land, is good practice compared to leaving the gap silent. The risk is specifically in what a documented, working placeholder looks like from every other vantage point in the meantime: every screen renders correctly, every guard fires, every permission check returns an answer — there is no error, no missing feature, no broken build to notice. The placeholder does its job so convincingly that the very fact it needs replacing can stop being visible to anyone not reading that specific comment, for as long as the surrounding feature work continues to ship successfully around it.

Centriu Helix's permission-checking hook is consulted by a single route guard component wrapping every one of the module's 336 screens — a deliberately centralized design, meaning exactly one implementation decides access for the entire product surface. Before this fix, that hook's implementation was a hardcoded array containing all 267 permissions the module's type system defines, returned unconditionally alongside an internal flag marking the result as a placeholder — with a code comment stating the real, centrally-managed permission system was intended to be wired in during a later phase of development. Every screen behind the guard, without exception, was reachable by any authenticated person for as long as that placeholder remained the only implementation.

The fix replaces the hardcoded return with a real, server-resolved permission set, read fresh on every request from the same central identity and access tables Centriu's own "Users and Access" administrative panel already writes to — a person's organizational membership record and role, plus any explicit per-user override or per-role organizational baseline recorded in the platform's central permissions table. Because no organization had, at the time of the fix, ever explicitly configured Helix access through that central panel, a role-based default policy was built specifically to govern that universal starting case: an executor role can view a feature and request review of it, but cannot approve changes or initiate a rollout; a sales-oriented role sees only commercial material; a client-facing role cannot operate the product on behalf of the agency serving them; and an unrecognized role receives nothing at all. The policy classifies each of the 267 permissions by matching meaningful terms directly in the permission's own name — sensitive, approve, manage, request, internal, and plain read access — rather than maintaining a separate, hand-curated list that would need updating every time a new permission is added and would silently go stale the moment someone forgot.

That term-matching approach caught a real classification bug of its own during testing: a permission controlling visibility of an automation kill-switch happened to be classified as ordinary read access, because the specific term that should have flagged it as engineering-sensitive did not match broadly enough against that permission's actual name. The matching terms were widened specifically to catch this case, with a dedicated test asserting the exact permission stays correctly restricted going forward. Every exit path through the resolution logic — no active session, no active organizational membership, an unrecognized role, or any database query failure — now returns an empty permission set rather than any form of default grant, and the guard component itself gained a dedicated loading state so that privileged content cannot flash briefly on screen before the real, resolved answer arrives and potentially removes it.

The fix's own verification deliberately measured what gets DENIED rather than only what gets granted — a direct consequence of the original defect being "grants everything," which a grant-only test suite would have continued to pass against even with the fix only partially applied. Run for the first time against real production data, the new check surfaced a genuine, previously invisible configuration gap of its own: the great majority of active members across the organizations using Helix — including, in at least one confirmed case, an organization's own owner — had never actually been granted Helix access in the platform's central access-configuration record at all. The module had functioned for everyone regardless, purely because nothing had ever actually checked. That gap was closed operationally, at the direct request of the affected owner, by explicitly granting access in the specific organizations where they hold an administrative role; every other affected member's record now honestly reflects the access they actually hold, rather than an access state nothing had ever verified.

Before the fix, any person able to log into Centriu at all — regardless of their actual role or organization — could navigate directly to any of Helix's 336 screens, including an automation kill-switch, LGPD audit records, and confidential per-client notes, and the route guard protecting each one would render normally and grant access, because the single hook it consulted always said yes. After the fix, the same navigation attempt is evaluated against the person's real, centrally-recorded role and organization-specific access, with an unrecognized or unconfigured case defaulting to no access at all rather than full access.

Access to Centriu Helix's 336 screens — including its most sensitive administrative surfaces — now depends on a person's real, centrally-managed role and organization-specific access configuration, evaluated fresh on every request, with every failure mode defaulting to deny. The same fix surfaced and closed a genuine, previously unmeasured access-configuration gap affecting the majority of active members across the organizations using the module.

This automation governs only Centriu Helix's own internal route-level permission checking — it does not change what any individual permission actually allows a person to do once granted, and does not affect the underlying database-level row-level security, which the guard's own documentation explicitly identifies as the real, unconditional access boundary regardless of what this UX-layer guard decides to render.

A hardcoded, universally-granting placeholder, clearly documented as temporary, is a legitimate way to unblock UI development ahead of a larger permission system landing — its risk is not in existing, but in how invisibly it continues to function once it does. The alternative is not merely "replace the placeholder eventually" but specifically building the eventual real check to fail CLOSED on every path a permission system can fail — an unrecognized role, a missing membership, a database error — so that even an incomplete rollout of the real system (as the universal absence of any organization-configured Helix access demonstrated it would be) defaults to the safer of the two possible wrong answers.