Panelbotdocs
SearchStart free

How Panelbot works end to end

See how you, your customer, and your servers connect in Panelbot, and how identity, ownership, and every action are checked at each layer on their own.

Three parties, one chain of trust

Panelbot connects three parties: you, the hosting company; your customer; and your servers. Understanding how they relate is the fastest way to understand how the product keeps your servers safe while still being genuinely useful in a chat window.

The important idea is that a customer’s request travels through several independent checks before anything touches a server. No single check is trusted to be enough. Each one stands on its own, and if any one of them says no, the request stops there.

The three parties

  • You, the hosting company. You connect your billing portal and your servers, choose what the assistant may do, and see a record of every conversation and every action. You set the boundaries; Panelbot works inside them.
  • Your customer. They open the chat on your portal and describe a problem in their own words. They never touch your dashboard and never reach your servers directly. Their only entry point is the chat.
  • Your servers. Panelbot reaches each server over the cPanel/WHM or DirectAdmin API with a scoped credential you grant, and carries out the specific checks and fixes you have enabled, and nothing else. Nothing is installed on the server by default. Your servers do the work, but only work that has been approved in advance and that the credential allows.

The trust chain, step by step

When a customer asks for help, here is the path the request follows before any server is touched.

1. The customer proves who they are through your portal. Because the chat runs on your billing portal, your portal vouches for the customer’s identity with a secure token. Panelbot does not take the customer’s word for who they are; it relies on the portal you already trust to sign them in.

2. Panelbot verifies that proof. The token is checked before the conversation gets any access to your services. An unverified or expired sign-in gets nowhere.

3. Panelbot confirms the customer owns what they are asking about. This is the check that matters most. Before anything touches a server, Panelbot looks up, in your connected billing portal, whether this customer actually owns the domain or service in question. If they mention a domain that is not theirs, the request is refused. This decision is made in code against your records, not by reading the chat, so it holds no matter what the customer types.

4. Only then does Panelbot act, and only on the right server. Once identity and ownership are confirmed, Panelbot runs a pre-approved check or fix on the one server that actually hosts that customer’s account, using the credential you granted for that machine. The instruction is scoped to that customer and that server, so it cannot be redirected elsewhere.

Each of these steps is verified on its own. Passing one does not grant the next. A valid sign-in still faces the ownership check; a confirmed owner still only ever reaches their own server with an operation from the approved list.

A simple way to picture it

   Your customer
        |
        |  describes the problem in chat
        v
   Your billing portal  ---> confirms who they are
        |
        v
   Panelbot            ---> verifies the sign-in
        |              ---> confirms the customer owns the service
        |              ---> chooses a pre-approved operation
        v
   The one server that hosts that account
        |
        v
   Result, explained to the customer and recorded for you

Read the diagram top to bottom as a series of gates. The request only reaches your server after it has passed identity, verification, and ownership, in that order. Nothing skips ahead.

Why it is built this way

A support tool that can touch production servers is only as trustworthy as the checks standing between a chat message and a command. By separating identity, ownership, and action into independent layers, Panelbot makes sure that breaking or fooling one layer does not open the rest. A convincing message cannot manufacture ownership. A verified customer cannot reach a server that is not theirs. And no layer hands the AI the authority to decide who is allowed to do what.

Where to go next