AI Agent and BYO LLM Key Cross-Tenant Selection Automation: The Only Active Key Belonged to Someone Else

Running one process per organization is a perfectly reasonable way to operate a system, and for as long as it holds, a query with no organization filter looks identical in its behavior to one that has been correctly scoped — every request the process ever handles genuinely does belong to the one organization it was configured for. The gap that convention hides only becomes visible the moment that assumption stops being universally true — a shared process, a migration in progress, an internal environment reused for more than its original purpose — at which point the query keeps confidently returning whatever the table's first-priority row happens to be, for anyone who asks.

Centriu Synapse's runtime, while actually answering an incoming customer message, calls two functions to decide how to respond: one selects which of the organization's configured custom AI agents applies, the other selects which bring-your-own LLM provider key to bill the call against. Before this fix, both functions issued the same shape of query: select every active row from the table, with no organization or tenant condition at all. The organization boundary that should have applied was never expressed in the query — it existed only as an operational convention, one deployment process per organization, which the query itself had no way to enforce or even know about.

A direct, dated measurement against a real deployment made the gap concrete rather than theoretical: querying the bring-your-own key table for the organization one specific deployment was configured to serve found exactly one active key in the ENTIRE table — and that key belonged to a different organization altogether, one used for internal purposes. The function's own log line at the time read "using the tenant's own default key" — an accurate description of the code's intention, and a false description of what it was about to do. The very next real customer message routed through that deployment would have been answered, and billed, using a key that organization never connected and never authorized.

The fix threads a `TenantScope` — organization id, and optionally a more specific sub-tenant id — through both functions as a required parameter, never an optional afterthought and never read from request configuration. Every query now applies that scope as a real database condition, layered with a second, independent check: after the database returns rows, each one is re-verified in application code against the same scope before being used at all — defense in depth against the theoretical case of a filter condition built incorrectly and silently returning too much. The in-memory cache that avoids re-querying on every message is keyed by the scope itself, not just by resource type, so a cached list computed for one tenant can structurally never be handed to a different tenant's request. Looking up a specific key by its own database id — the path a custom agent's own configuration uses to reference "its" key — resolves only inside the map that has ALREADY been filtered to the caller's scope, so a key id belonging to a different organization is indistinguishable from an id that simply does not exist, which is the correct answer for a resource that isn't the caller's. And when the database cannot confirm the scope columns exist at all — the specific migration state where scoping information might genuinely be unavailable — every one of these functions fails CLOSED, returning nothing, rather than falling back to an unscoped read that could hand back anyone's data.

A deployment serving one organization's customers receives a real inbound message and needs a bring-your-own LLM key to answer it. Before the fix, the selection function asks the database for "the active key," gets back a single row — because, in this specific measured case, only one active key existed in the entire table — and uses it without ever confirming which organization it belongs to. The message is answered, successfully, using and billing a completely different organization's connected credential. After the fix, the same selection first narrows the query to the caller's own organization and tenant; finding no key that belongs to it, the correct response is to report that no key is configured — not to reach across the table for whichever key happens to be there.

Centriu Synapse's runtime can no longer select a custom AI agent or a bring-your-own LLM key belonging to an organization other than the one an incoming message is actually being answered for — every selection requires and verifies an explicit tenant scope, at the query, the cache, and the row level.

This automation governs how Centriu Synapse's own runtime selects which internal resource (agent, key) applies to a message it is already processing — it does not change how a customer connects or manages their own keys through the product's own interface, and it is distinct from Centriu's separate internal admin panel for API-key administration, which is its own, separately secured surface.

Relying on "one process per organization" to keep data separated is not unreasonable as a starting architecture — it is simple, and for a long time it is even correct in practice. The cost only shows up later, and it shows up as a query that has no idea it is supposed to be scoped, which means it also has no way to fail safely when the topology assumption stops holding. Making the scope an explicit, required parameter at every read — rather than an emergent property of how the system happens to be deployed — means the correctness of the boundary no longer depends on an operational fact nobody wrote down.