AI Persona Tenant-Ownership Scoping Automation: Every Tenant, Wearing One Customer's Identity

Storing one customer's branded content as the default that loads for everyone, with a scoping rule layered on top to restrict it back down to just that customer, is a workable design — right up until something removes the scoping rule and leaves the default standing on its own. A default that was never meant to be a default in the first place does not announce itself as broken when its guard disappears. It keeps loading exactly as it always did, for exactly the audience it was designed to reach before the guard existed — which, after the guard is gone, is now everyone.

A specific paying customer on Centriu Synapse's shared AI deployment maintains its own custom system-prompt files — the instructions that establish the AI agent's name, tone, and behavioral identity for that customer's own use case. Those files live on disk as part of the shared codebase's default configuration, loaded into every tenant's conversational turn through the same file set, UNLESS something restricts them.

A guard added in the codebase's history was built to do exactly that restriction: when an environment variable declaring the owning organization's identifier is set, the disk-based default files are loaded only for that one organization; every other tenant is meant to fall back to its own content, sourced from either a database-stored override specific to that tenant or a tenant-specific override folder on disk. An unrelated revert later deleted the guard function itself, while the environment variable declaring the owning organization stayed configured on the running deployment, now read by nothing.

A systematic audit of everything that same revert had touched — triggered by the practical question "which of the 132 test files that revert deleted were guarding code that is still alive today," not by any specific complaint — surfaced this gap directly: with the guard gone, the disk-based default files (confirmed, by direct inspection, to open with a first-person identity statement naming the owning customer's brand) were once again the unconditional default for every tenant. Checking both intended safety nets at the moment of this discovery found the database override table with zero rows, and the tenant-specific override folder simply absent from the filesystem — confirming neither had ever been exercised in practice. Every tenant served by this deployment, including the platform's own default operating organization, would have had its AI agent's underlying identity instructions come from that other customer's branded content instead of generic, or its own, default identity.

Restoring the guard function alone would not have been sufficient. The guard needs to know, for the current conversational turn, which organization is actually asking — a piece of context that had not previously been threaded through to the function responsible for assembling the AI's system prompt. Without that one additional piece of wiring, the restored guard would see an undefined organization for every turn, which is not a match for the declared owning organization, and would therefore correctly, but overly broadly, block the branded content even for the customer who legitimately owns and pays for it — trading a leak for a full outage of that customer's own configured product. The fix pairs the restored guard function with the one line connecting the orchestrator's own knowledge of the current turn's organization into the prompt-building context it was missing, so the guard can now tell the difference between the rightful owner and everyone else, correctly, on every turn.

A completely unrelated customer, using their own Synapse-powered AI assistant for their own business, has that assistant's underlying system instructions include another customer's brand identity statement, invisibly, in the background context shaping every response — not because anyone configured it that way, but because the guard that was supposed to prevent exactly this had been quietly removed by an unrelated change weeks earlier, and neither of the two safety nets meant to protect this customer had ever actually been used by anyone. After the fix, the same customer's assistant is built exclusively from its own configuration and Centriu's own generic defaults — the other customer's branded content never enters the picture unless that specific customer, and only that customer, is the one being served.

Centriu Synapse now scopes one customer's own branded AI-identity content strictly to that customer, with the guard enforcing it correctly wired to know, on every conversational turn, which organization is actually being served — closing a window in which a reverted guard, combined with two never-used safety nets, would have let that content reach every tenant on the shared deployment by default.

This automation governs how Centriu Synapse scopes one specific customer's own custom AI-identity configuration on a shared deployment — it does not describe a general-purpose white-labeling feature available for a customer to self-configure, and does not apply to the newer agent-based conversational path, which does not use this file-based configuration mechanism at all.

Loading a specific customer's branded content as an unconditional default, protected only by a guard layered on afterward, works only as long as nobody or nothing ever removes that layer — and a refactor, a revert, or a merge conflict resolved the wrong way is exactly the kind of change unlikely to notice a guard it never touched directly. Content scoped to a named, explicit owner from the start, with a guard that fails closed when ownership cannot be determined, survives exactly the kind of unrelated change that deleted this protection the first time — because the failure mode of "ownership unclear" is withholding the content, not handing it to whoever happens to ask.