Panelbotdocs
SearchStart free

Tenant isolation

Every hosting company on Panelbot, and all of their customers, is strictly separated. One company's credential can never be used for another's work.

Strict separation, treated as sacred

Panelbot serves many hosting companies at once, and each of them serves many customers. The single most important promise underneath all of that is separation: your data, your servers, and your customers are yours alone, sealed off from every other business on the platform and from each other. Here is how firmly that line is held, and why we treat crossing it as the worst thing that could happen.

Between hosting companies

Every hosting company that uses Panelbot is walled off from every other one. Your servers, your billing connection, your team, your widget settings, and your customers’ conversations belong to your account and are never visible to another company on the platform. There is no shared pool where one operator could stumble into another’s data, and no view that spans across businesses.

This separation is enforced by the system itself, not by asking anyone to be careful. Every request is bound to the account it belongs to, and a request for one company’s data simply cannot return another company’s information. The boundary is a property of how the platform is built, which is why it holds under load, under mistakes, and under deliberate probing alike.

Between your own customers

The same discipline applies one level down, among your own customers. When a customer opens the chat, the assistant works only within that customer’s own services. It confirms, in code and against the records synced from your billing portal, which accounts and domains belong to that person, and it helps within that set and nothing else.

A customer cannot reach another customer’s site, mailbox, or account, even by accident and even if they word the request cleverly. Ownership is settled before anything runs, and the chat has no power to expand it. One customer’s conversation, and everything the assistant learns during it, stays with that customer and never bleeds into anyone else’s session.

Your servers only take instructions meant for them

The credential you grant for a server is scoped to you and to that one machine. It is stored encrypted, used only for work that belongs to your account, and can never be borrowed for another company’s server or another company’s customer. Revoking it on the panel side ends the access at once.

If you install the optional agent, the same holds there: an agent running on one hosting company’s server can only ever receive instructions intended for that company and that specific machine. Every instruction sent to it is cryptographically signed and scoped to a specific account and a specific machine, and the agent confirms that before it acts. An instruction cannot be forged, cannot be replayed against the wrong server, and cannot be redirected from one customer to another. If one of your machines were ever compromised by an unrelated attacker, the agent there would still only ever see the instructions sent to that one machine. It holds no map of what Panelbot can do elsewhere and no keys to anyone else’s servers.

Why we treat a leak as the highest severity

A cross-account leak, where one business or one customer could see or affect another, is the most serious failure we can imagine in a system like this. We treat it that way. It sits at the top of our severity scale, above an outage, above almost anything else, because trust in a shared platform rests entirely on the guarantee that shared never means mingled.

That framing shapes the design. Separation is not a feature bolted on at the end; it is the assumption every other part is built around. Requests carry their scope with them, servers verify what is meant for them, and ownership is checked in code every time rather than inferred from a conversation. The result is a platform you can put in front of your customers knowing that your business, and each of theirs, stands on its own.

Where to go next