Public Trust Center Admin-Authorization Automation: The Gate That Wasn't in the Screen — Or the Database

A settings page that only shows a "Save" button to the right people creates a strong, correct-looking impression of access control — nobody who shouldn't be able to make the change can see how to trigger it from the interface. What that impression leaves out entirely is that a web application's interface and its actual data layer are two separate things, and only one of them is impossible to route around: anyone who already has a valid, logged-in session can, in principle, call the exact same write endpoint the hidden button would have called, without ever loading the screen that hid it. A role check that lives only in what the screen displays is a restriction on the path most people will take, not a restriction on what the system will actually accept — and for a screen whose entire purpose is publishing something to the public, that distinction is the whole ballgame.

Most screens inside a product built for many separate organizations at once only need one kind of protection: making sure organization A can never see or touch organization B's data, which is exactly what data isolation by organization, enforced at the database level and scoped to `organization_id`, accomplishes on its own. Inside a single organization, most everyday actions — creating a client, starting a session, adding a task — are intentionally left open to any team member, because restricting them further would slow down normal work for no real security benefit. A public-facing Trust Center admin screen is a structurally different kind of surface: it isn't "my organization's working data," it's the organization's public face, and the one thing that should distinguish it from every other same-organization screen is precisely the role-based restriction that everything else in the product deliberately doesn't need. That difference is easy to miss specifically because the org-isolation policy already looks like real security — it correctly stops a different tenant from reaching the data — and nothing about a working, correctly-isolated policy signals that a second, role-based layer was also supposed to exist on top of it.

The gap surfaced as part of the same internal audit that rewrote Axiom's proof-of-action mechanism and connected its safety scanner to the real AI path (both covered on this pillar's companion pages) — a recurring pattern of a control that looked complete without actually being wired all the way through. For the Trust Center admin screen specifically, the finding was direct: the screen itself performed zero role checks, and the row-level security policies backing both `axiom_trust_documents` and `axiom_subprocessors` were a single `ALL`-scoped rule each, restricting access only to rows belonging to the caller's own organization — with no further restriction on which member of that organization could write.

Before writing a single line of the fix, the audit checked the blast radius directly against production, read-only: both tables held zero rows at the time, meaning tightening the policy could not corrupt or orphan any existing data. It then checked exactly who would be affected by the change — 2 platform masters and 14 organization admins across the live data would retain write access exactly as before, while 10 staff-level members would lose a write capability they should never have held in the first place. Nobody with a legitimate need to publish or edit a Trust Center document loses access as a result of this fix.

The fix itself is deliberately layered as two separate, cooperating pieces rather than one. The database migration adds a new function, `axiom_user_is_admin()`, that returns true only for a platform master or for a member whose role in the organization currently active for that request (respecting the same org-switcher logic the rest of the app already uses) is admin, administrador, or master — a direct, role-for-role mirror of the exact `mapUserRole` function the application's own UI already uses to decide what to show. That mirroring is deliberate: if the UI's notion of "admin" and the database's notion of "admin" were two independently-maintained definitions, they could drift apart over time and quietly disagree about who is actually allowed to write, with the interface offering a button the database would refuse or — worse — the database silently accepting a write the interface never should have permitted. The migration replaces each table's single organization-scoped policy with four narrower ones: read stays open to the whole organization (the Trust Center itself needs every member to be able to see what has already been published), while insert, update, and delete each now additionally require `axiom_user_is_admin()` to return true. The update policy specifically carries the same admin check in both its `USING` clause (which existing rows can be touched) and its `WITH CHECK` clause (what the row is allowed to look like after the edit) — the second check exists specifically to close a subtler gap: without it, an admin editing a row could in principle move it to a different organization entirely as a side effect of the update, since `USING` alone only governs which rows can be selected for editing, not what the edited result is allowed to contain.

The screen-level half of the fix adds a genuine role check to `TrustCenterAdmin.tsx` itself: while the current user's role is still loading, the page shows a loading state rather than rendering anything; once resolved, anyone who is not an owner or admin sees a plain, honest restricted-access message directing them back to the read-only Trust Center, instead of the admin interface. The page's own code comment is explicit about what this half actually is and isn't: a screen-level gate alone would be decoration, since anyone who wanted to write anyway could still call the underlying API directly with their own valid token — the database migration is described in that same comment as "the half that matters." Confirmed directly in the current source: both the UI check and the database function remain in place today, unmodified since the fix.

A staff member without any admin role opens the Trust Center admin screen and is shown the restricted-access message — the UI gate working as designed. Suppose instead that same staff member skipped the screen entirely and called the underlying write endpoint directly with their own valid, logged-in session token, exactly as a browser's developer tools would allow. Before this fix, that request would have succeeded, because the database itself imposed no role requirement — only the now-bypassed screen ever asked the question. After the fix, the identical direct request is refused by the database's own row-level security policy, independent of whether any screen was ever involved.

A document that is shown to the public as an organization's official privacy policy or subprocessor list can now only be created, changed, or removed by someone the database itself — not merely the interface — recognizes as an owner or administrator of that organization. The restriction survives being called from a different client, a different screen, or no screen at all, because it lives in the one layer that every possible path to writing that data has to pass through regardless.

This fix restricts WRITE access to published Trust Center documents and the subprocessor list to owners and admins — it does not restrict READ access, which intentionally remains open to every member of the organization, since the whole point of the Trust Center is that anyone inside the company can see what has already been made public. It is also a role gate, not a multi-step review or approval workflow: an admin's edit takes effect immediately, without a second person needing to approve it first. A team specifically wanting a publish-approval queue on top of this restriction would need that as a separate, additional mechanism.

A role check built only into an interface restricts the path most people will take, but does nothing about a request made directly against the underlying API with a valid session token — which is precisely how a determined bypass, or simply a different, unaudited client built later, would reach the same data. Centriu Axiom's fix closes that exact gap by putting the real restriction in the database itself, using a function that mirrors the interface's own definition of "admin" so the two layers can't quietly drift apart and disagree.