Security

Is AI support safe? The model never touches your servers

That is the first question every hosting operator asks, so here is the whole answer. PanelBot connects to cPanel or DirectAdmin over the panel API with a scoped credential, and nothing of ours runs on your server by default. Safety is structural, not behavioral: the AI can only compose requests, and a separate layer of plain code verifies, confirms, runs, and records. Including the attacks it shrugs off and the things we refuse to do.

The split

Is AI support safe for hosting? Two programs, and only one can act

The part of PanelBot that talks to customers and the part that touches servers are different programs with different powers. The one that talks has none. Not a restricted shell, not a sandboxed API. None.

Its only output is a request, and a request is not an action until the execution layer has verified who owns what, collected the confirmations, and decided your policy allows it.

The rules

Risk has rules, and the rules are code

The same checks run no matter how persuasive the conversation was.

Read-only checks run on their own

no confirmation needed

Anything that changes the account waits for the customer’s yes

enforced in code

Deletions add the exact name, typed into a form

enforced in code

Terminations, suspensions, whole-account restores go to your team

always human

Field-tested attacks

Prompt injection, demonstrated

These attacks are not theoretical. A car dealership’s chatbot famously agreed, in writing, to sell a $76,000 SUV for one dollar. A courier’s bot was talked into swearing at its own customers. The patterns are public, so we test against the real ones.

Here is why they go nowhere: the model’s words are just words. Actions exist only as requests to the execution layer, which checks ownership and waits for confirmations a prompt cannot fake. The most an injection ever wins is a polite no, on the record.

actions executed: 0 · attempt recorded in audit

On your machines

Agentless by default: nothing lands on your server

PanelBot connects to cPanel/WHM or DirectAdmin over the panel API, with a credential you scope and can revoke at any time. A reseller credential is enough. When a server connects, PanelBot probes what that credential allows and shows you the list before the first chat: what it can read and change, and what it cannot. It never sees billing, never changes your root password, and never reads customer passwords.

The connector that registers the server lives in your own portal as plain code you can read, and no secret is ever displayed in the open. For the few jobs a panel credential cannot reach on your setup, there is an optional agent: plain, open code that runs unprivileged; root-only commands go through a fixed sudoers allowlist on your server. Its whole job is to run the one approved action it is handed and report back.

Credentials

Passwords never exist in a transcript

A password in a chat log is a password waiting to leak. So they never go through the chat. New credentials are generated by the system into a one-time secure field: never typed by anyone, never stored anywhere, destroyed from our records the moment the chat ends.

If a customer pastes a password into the conversation, PanelBot refuses it and a fresh one is issued the safe way instead.

Your data

Who sees what

The customer’s browser

Only what it needs to draw the chat. Sensitive context stays server-side.

Your team

What each role allows. Owners, admins, technicians, and viewers see different things, and access itself is logged.

PanelBot staff

Nothing. Your conversations, audit, and knowledge base are tenant-isolated and out of our reach. The single exception is below, and you hold it.

Kept, on the record: transcripts, the checks that ran, their results, and the audit trail. Never kept: passwords, payment data, or anything belonging to another tenant.

The one exception, and you hold it

We cannot read your conversations. So when you think a chat went wrong, wrong answer, wrong checks, you escalate that one conversation to us from its page. It opens a ticket on your behalf and shares that chat with its check history. Nothing else.

Revoke the access at any moment. It also revokes itself the moment the ticket closes.

Audit

Every step is logged, and the log is the record

No edit, no delete through the product, not even for an Owner. Kept for 12 months. Replay any conversation from the last 90 days end to end, see which checks ran and what they found, and export it per conversation for a compliance review.

This entry is the subdomain deletion from the how-it-works page. The story you read there is a record here, which is the point.

The short list

What it refuses to do, no matter who asks

  • Terminate an account from chat. Always a human.
  • Suspend or unsuspend service. Always a human.
  • Restore a whole account or home directory. Always a human.
  • Touch payment methods, invoices, or charges. Billing context is read-only.
  • Make offers, discounts, or commitments. The model has no authority to bind you.

The hard questions

What seasoned admins ask us

Does PanelBot ever have root on our servers?

By default nothing of ours runs on your server at all. PanelBot talks to cPanel/WHM or DirectAdmin over the panel API with a credential you scope and can revoke, the same way your billing portal already does. A reseller credential is enough. The optional agent, for the few jobs a panel credential cannot reach, runs unprivileged; root-only commands go through a fixed sudoers allowlist on your server, and it is plain, readable code you can open before it runs.

Can we see exactly what it can and cannot touch?

Yes, before the first chat. When a server connects, PanelBot probes what the credential you granted allows and shows you the list: what it can read and change, and what it cannot. It never sees billing, never changes your root password, and never reads customer passwords. The connector file in your portal is plain code you can read too, with no secret ever shown in the open.

Can PanelBot staff read our conversations?

No. Conversations, audit records, and your knowledge base are scoped to your tenant at every boundary, with no staff-side view into your content. The one exception: you can escalate a specific conversation to us for review, and you can revoke that access at any time.

What can it run without asking?

Read-only checks, nothing else. Anything that changes an account waits for the customer’s yes, deletions also need the exact name typed, and the critical few always go to your team.

Can the model be talked into running something?

No, and not because the model is well behaved. Its words never become actions. Every action is a request to a separate code layer that checks ownership and waits for confirmations a prompt cannot fake.

What does a stolen portal session expose?

Only that one customer’s own services, with every confirmation still required. The widget carries nothing belonging to other accounts, so there is nothing extra to steal from it.

Where do confirmations live afterward?

In the audit log, which cannot be edited or deleted through the product: who acted, what ran, when, and both confirmation steps. Filter it, replay it, export it to CSV for a compliance review.

Found a vulnerability? We want it. Write to security@panelbot.io and a human reads it, fast.

Put it on your portal this week.

Start free on your own WHMCS or Blesta install. 30 conversations a month, no card, cancel anytime.