Admin API-Key Panel Organization Resolution Automation: The Panel Managed Keys for the Wrong Organization

A deployment-time constant answers a fair, narrow question: which environment is this process running in, which database does it point to, which default account does it operate under absent any other instruction. Reusing that same constant to answer a completely different question — which organization's data is this specific administrative operation actually about — quietly assumes the two questions always have the same answer. They usually do, until an operational reality (a shared admin tool serving more than the deploy's own default account) makes them diverge, at which point the constant keeps confidently answering the first question while everyone reading its output assumes it's answering the second.

Centriu Synapse's internal admin panel exposes three routes for managing API keys: list the existing ones, create a new one, and revoke an existing one. Every one of those three routes, before this fix, read the exact same source for "which organization is this operation about": a single configuration constant set at deploy time, representing the organization the deployment's own configuration names as its default.

Confirmed directly in production: the organization that constant names, and the organization the running process was ACTUALLY serving real traffic for, were two different organizations. The consequence follows directly — the admin panel could successfully list, create, and revoke API keys, but only ever for the organization named in the deploy constant, never for the organization the process was genuinely operating on behalf of. The real key operations for the organization actually being served had to happen through some other means entirely, outside whatever oversight the admin panel was built to provide.

The fix introduces an explicit three-part resolution: first, an operator-configured list (via an environment setting) declaring which organizations THIS specific process is allowed to administer at all — when nothing is configured, the only administrable organization remains exactly the deploy constant, preserving prior behavior exactly for anyone who never opted in to the new mechanism. Second, a request-level header lets the caller PROPOSE which of the allowed organizations to operate on for this specific call — a proposal, never a decision on its own. Third, that proposal is checked against the configured allowlist, and only a match becomes the operation's real, effective organization.

Every way that resolution can fail is returned as its own distinctly typed, machine-readable refusal: an invalid identifier format, a required selection that was never made (when more than one organization is allowed and the caller didn't say which), no administrable organization configured for the process at all, and — deliberately, by design — the SAME refusal code for "that organization exists but isn't on this process's allowed list" as for "that organization doesn't exist at all." That specific design choice is intentional: distinguishing the two would let anyone with access to the panel use it as a tool to test whether an arbitrary identifier corresponds to a real organization, turning an authorization check into an information leak about what exists.

The fix is also explicit about what it deliberately does NOT attempt. Synapse has no model connecting a specific PERSON to a specific organization at all — admin routes authenticate via a shared token, and a logged-in session carries only a role (administrator or viewer), never an organization identity. That means "a real person without the right permission gets refused" is not a claim this fix can verify today, and the commit's own text states plainly that no test pretends otherwise — inventing an improvised identity layer just to make that claim testable would itself be a worse design than the constant it would replace. The gap is recorded explicitly as a named, open item for a future, deliberate identity model — not quietly assumed away.

An administrator opens the internal API-key panel to review or revoke a credential for the organization the process is actually serving customers for. Before the fix, every list, create, and revoke action silently operates against a DIFFERENT organization entirely — the one named in the process's own deployment configuration — returning clean, successful-looking responses the whole time, because nothing about the request or the response format reveals that the wrong organization was ever in play. After the fix, the same administrator's request must resolve to an organization the process is explicitly configured to allow, is available to select when more than one exists, and returns a specific, typed error rather than a misleading success if that resolution ever fails.

Centriu Synapse's internal API-key admin panel now resolves which organization a given operation targets from an explicit, operator-configured allowlist and a per-request selection, rather than a single deploy-time constant that could — and in production, did — name a different organization than the one actually being served.

This automation governs Centriu's own internal administrative tooling for managing API keys — it is not a customer-facing feature, does not add a general person-to-organization permission model (a named, explicit, and honestly-reported gap in the current design), and does not change how a customer's own connected credentials are used or scoped in their day-to-day product experience.

A single deploy-time constant is simple and correct for exactly as long as a process only ever needs to answer on behalf of one organization — the moment that assumption stops holding, the constant doesn't fail loudly, it just keeps confidently answering the old question for a new, wrong context. An explicit allowlist paired with a per-request, checked proposal costs a little more to configure up front, but it fails the RIGHT way: a typed, visible refusal instead of a silent, successful operation against the wrong organization's data.