Member-to-Member Mutation Boundary Automation: Who May Touch a Row Is Not What They May Change In It

A row-level security policy answering who may access a specific database row is a genuinely strong, foundational access control — and for a record that belongs entirely to one person, answering that single question is often sufficient on its own. The gap opens specifically for a TWO-SIDED record: a row that legitimately belongs, in some sense, to two different people at once (a request has a sender and a recipient; a deal has a party who reports an outcome and a party who confirms it). A policy that grants either party access to the shared row, using the identical expression for both reading and writing, has correctly identified who may touch the row — and has said nothing at all about which specific fields within that row belong to which party's own side of the transaction. Every write either party makes passes the same single check, regardless of which half of the row it actually changes.

Centriu Vértice's database enforces row-level security so that a member can only see and act on rows relevant to them — a genuinely strong default. For its two-sided records specifically — a connection request between a sender and a recipient, a business deal between a party who declares an outcome and a party who confirms it — the SAME policy expression governed both which rows a member could read and which rows a member could write to. That single expression correctly identifies that either party belongs to the shared row. It says nothing at all about which specific COLUMNS within that row represent which party's own contribution — so a write from either side, touching any field in the row, passes the identical check regardless of whose part of the transaction it actually changes.

Measured directly against the real production database, using a synthetic member's own genuine session token — precisely the level of access anyone reaches simply by copying their own browser's authentication cookie — five specific boundaries yielded to exactly this gap. A pending connection request could be altered by either the sender or the recipient's own direct write, moving it toward states neither had actually chosen through the product's real approval flow. Either party in an existing relationship could overwrite context the other party had separately submitted. Most consequentially: the party responsible for DECLARING a business deal's outcome could, through a single direct write, set the specific columns the product's own public network-health scoreboard reads as evidence of real business activity happening between members — meaning a number presented as an objective, measured fact about the network was, in practice, directly settable by the one participant with the clearest interest in that number looking favorable.

The fix, closing this alongside a related, larger residual (Centriu Vértice's own team documents it as deliberately scoped to this specific data family, leaving the remaining, separately-tracked broader table population for its own dedicated closure), does not attempt to solve the problem by writing a more elaborate row-level security policy that tries to encode a state-transition or field-ownership rule declaratively inside a SQL expression — the fix's own reasoning names that approach as fragile to write correctly and harder still to verify than the alternative actually chosen. Instead, direct write privilege for the ordinary, session-based database roles is revoked entirely across every table in the affected data family, leaving the product's own trusted, elevated internal write path as the sole route by which any of these records can actually change — a decision made safe specifically because a full inventory of every place in the product's own code that could write to this family, using a member's real session token, found exactly zero legitimate consumers. The privilege existed with no actual product feature depending on it at all.

A second, genuinely unlisted exposure surfaced specifically during the work of verifying that this fix actually closed everything it needed to: one specific database object in the affected family was not an ordinary table at all, but an auto-updatable VIEW — a database object that looks and behaves like a table for read and write purposes, built as a convenience layer over the real underlying data. That view was owned by a database role holding a privilege that bypasses row-level security entirely, and the view itself was not configured to enforce security under the identity of whoever was actually querying it. The practical consequence: writing through the view reached the real, underlying table with row-level security completely absent from the path — a revoke applied only to tables, however correctly scoped otherwise, would have left this one specific route to the identical data fully open. It is worth stating plainly why this was not caught by the product's own extensive automated verification: that verification's real, end-to-end browser-driven journeys interact with the actual table through the product's normal interface, not through a direct write to this specific view — a gap that exists in the view, rather than in what the ordinary product flow itself does, would simply never be exercised by that verification path at all. Both the table family and the view were closed together in the same fix.

Before the fix, the party responsible for declaring a business deal's outcome inside Centriu Vértice's network could, through a single direct database write reachable with nothing more than their own ordinary session, set the exact fields the product's own public scoreboard reads as proof of real economic activity between members — turning a number presented as objective, network-wide evidence into something a single interested party could set directly. A completely separate exposure, found only while verifying this exact fix, showed the identical underlying data reachable a second way: through a database view whose own configuration bypassed row-level security entirely, regardless of what the fixed table-level permission now enforced. After the fix, neither the tables nor the view accept a direct write from an ordinary member session — the scoreboard's figures now reach it exclusively through the product's own trusted, elevated internal path.

Centriu Vértice's connection, deal, and opportunity data family — including a database view that had separately bypassed row-level security through an elevated-privilege owner — no longer accepts a direct write from an ordinary member's own session token, closing five measured boundaries where either party to a shared, two-sided record could alter the other party's own contribution, most consequentially the columns the product's own public network scoreboard reads.

This automation governs the internal database write-boundary between two parties sharing a single record inside Centriu Vértice's own curated network — it does not change what a member can do through the product's own normal interface (the product's own trusted write path remains the sole, unaffected route for every legitimate action), and is specific to a two-sided-record access pattern; a system where every record belongs to exactly one party, with no shared-row concept at all, would not be exposed to this specific class of boundary gap.

Using one row-level security policy expression to govern both who may see and who may write to a shared, two-sided row is the simpler design, and is entirely correct for the "who" question — the gap is specific to the unasked "what" question, which only becomes visible once a row genuinely has two distinct parties with two genuinely distinct sets of fields they should each individually control. Revoking direct write privilege outright and routing every legitimate change through one trusted, elevated write path sidesteps the need to encode field-level, party-specific transition rules inside declarative policy expressions at all — at the cost of requiring every legitimate write to go through that one trusted path, which this fix confirmed, by full inventory, was already the case.