Internal Admin Panel Cross-Org Access Control Automation: A Revert Deleted the Guard and Left the Test File Explaining It

A code revert is a normal, often correct engineering action — undoing a change that turned out to be wrong. The risk sits specifically at the boundary of what a revert actually touches: when the change being undone happened to sit in the same files as unrelated, valuable protections added afterward, reverting can silently take those protections with it, and nothing about the act of reverting itself distinguishes "undo the mistake" from "also erase the fix that came after it." The codebase is left describing a safeguard that used to be true.

The starting point was a specific inconsistency: the internal admin panel's own test-runner configuration file still explained why a particular import alias mattered, and cited three specific test files by name to make that point — but all three files, and the protections they tested, were gone. Tracing why led to one earlier code revert, dated 18 days before this investigation, that had undone an unrelated change and, in doing so, deleted three genuinely separate organization-scope protections that had been found and fixed eight days before THAT revert happened, each with its own dedicated test file explicitly written, per its own header comment, "so this never goes missing again."

The first and most serious of the three: the function resolving who is allowed to authenticate as an administrator on the panel checked only that the requesting person belonged to some organization with Synapse module access — with no check at all for WHICH organization. Because the panel itself always operates on one specific, configured organization, this meant any team member with Synapse access anywhere across every one of Centriu's client organizations could authenticate successfully and then operate on a DIFFERENT organization's Synapse configuration than their own. Measured directly against the database: 8 people held that access, spread across 5 different organizations, and 7 of the 8 were outside the one organization the panel actually operates on. A separate, correctly-scoped check existed one step later in the same authentication flow — the working pattern was present in the very same file, just not applied at the earlier step where it mattered.

The second finding lived in the panel's own data-access layer: the function listing a client's saved AI provider keys read and decrypted keys belonging to EVERY organization in the database, with no organization filter applied at all, and the functions to update or delete a specific key acted purely by the key's own ID, with no check that the ID actually belonged to the caller's organization. A third, separately-scoped table used by the same panel had always filtered correctly by organization — meaning the correct pattern existed elsewhere in the same codebase, and simply had not been applied to these two.

The third finding was a direct, functional consequence of the same revert: the functions that create a new AI agent or a new provider key through the panel had stopped writing an organization identifier to the new record at all — and in production, that column is required with no default value. Every attempt to register a new agent or key through the panel had been failing outright with a database constraint error since the revert, which is the specific, confirmed reason the underlying table held zero rows. All three protections were restored to their exact pre-revert implementation — not rewritten from scratch — including a deliberate fail-closed design: when the organization context an operation needs is missing entirely, the operation is refused outright, rather than silently defaulting to operating across every organization at once.

A team member with Synapse access at one client organization opens the internal admin panel. Before the fix, the authentication check confirms only that this person has Synapse access SOMEWHERE — passes them through as an administrator — and the panel proceeds to operate on a different, specific organization's own Synapse configuration, one the person has no actual relationship to. After the fix, the same authentication check additionally confirms the person's access belongs to the exact organization the panel is about to act on, and refuses the session outright when it does not match — the same outcome a working, correctly-scoped check one step further down the same file had already been producing for a narrower case.

Centriu's own internal admin panel for Synapse can no longer authenticate a team member as an administrator for an organization other than the one their own access actually belongs to, and can no longer expose, alter, or delete another organization's provider keys by ID alone — closing a gap that had been silently reopened by an unrelated revert and left undetected for 18 days.

This automation governs organization-scope access control inside Centriu's OWN internal operator tooling for Synapse — it is not a customer-facing feature, and it does not change how a customer organization's own end users or AI agents authenticate within their own Synapse deployment.

The failure here was not that a revert happened — reverting a mistaken change is often exactly the right call. The failure was that nothing separated the mistake being undone from the unrelated protections that happened to live in the same files, and nothing flagged that the repository's own test configuration kept describing safeguards that had quietly stopped existing. Centriu's fix restores the specific protections verbatim and reattaches their own dedicated tests, closing the gap between what the codebase claimed to guarantee and what it actually did.