Safety and permissions
The Panelbot trust model in plain terms: the AI only translates, actions come from a pre-approved list, ownership is checked in code, all logged.
The trust model, in plain terms
Letting an automated assistant work on production servers is a serious thing to ask of any operator. Panelbot is designed so that the answer to “what could go wrong” is bounded and knowable. This page lays out the guarantees that make that true. None of them depend on the AI behaving well, because none of them are enforced by the AI.
The AI never executes anything
Start here, because it is the foundation. The AI’s entire job is to translate: it reads the customer’s message, works out which known type of problem it describes, pulls out the relevant details, and puts replies into plain words. It does not run anything.
When an operation needs to happen, it is not the AI that decides to run it. The system decides, in code, based on the type of issue, your settings, and what the customer is confirmed to own. The AI is a translator between your customer and that code, and nothing more. A support tool that “asks the AI to run a command” is exactly what Panelbot is not.
Every action comes from a fixed, pre-approved list
Panelbot cannot run arbitrary commands on your servers. It can only run operations from a fixed set that has been defined and approved in advance. Each one is a narrow, specific task, checking a mail queue, reading a site’s status, looking up a certificate, and there is deliberately no general-purpose “run anything” operation anywhere in the system, not even a gated one for emergencies.
This means the worst case is bounded. The assistant’s reach is the approved list, and that list is made of small, well understood operations, not open-ended access.
Ownership is checked in code, not by the AI
Before Panelbot touches anything, it confirms that the customer actually owns the service in question. That check runs against the records in your connected billing portal, in code, independent of the conversation. If a customer refers to a domain that is not on their account, the request is refused, regardless of how convincingly the chat is worded.
The AI is never the thing that decides who owns what or who is allowed to do something. Those authorization decisions are made outside the AI entirely, so a persuasive or manipulative message has nothing to work against.
Changes are graded by impact and gated accordingly
Not every operation carries the same weight, so Panelbot treats them differently based on how much they could affect.
| Impact level | How Panelbot handles it |
|---|---|
| Read-only checks | Run automatically. They gather information and change nothing. |
| Low-risk, reversible changes (single account) | Run only if you opt in. Off by default; you decide. |
| Higher-impact changes | Require explicit human approval, by default a person on your team. |
| The most dangerous class of change | Not available to the assistant at all. |
The read-only checks are where the assistant does its investigating, safely, because they cannot change anything. Reversible single-account fixes are yours to enable or leave off. Anything with wider impact stops and waits for explicit human approval, by default one of your people, every time. One optional setting you control adds a single further path: a narrow, clearly scoped class of destructive actions, such as deleting a database, removing an addon domain, or restoring specific files or a folder from a backup, can complete in chat after the customer passes a strong confirmation, typing the exact name and confirming a final time. It is off by default, your choice to enable, and fully logged. And the most dangerous class of operation, such as terminating an account or restoring an entire account from backup, is never exposed to the assistant either way; no setting enables it in chat.
The connection to your server is deliberately limited
By default, nothing of Panelbot runs on your server. Panelbot talks to cPanel/WHM or DirectAdmin over the panel API with a credential you grant, the same way your billing portal already does. That keeps the boundary simple and visible:
- The credential is scoped. A reseller credential reaches only what that reseller can reach; a root or admin credential reaches more. You choose, and you can revoke it on the panel side at any moment.
- When a server connects, Panelbot checks what the credential allows and shows you the list, so you know before the first chat what it can and cannot touch. It never sees billing through the server, never changes your root or admin password, and never reads customer passwords.
- It can only carry out the pre-approved operations, and only those the credential permits. There is no arbitrary command path.
Panelbot takes that limited credential even when your billing portal holds a root credential for the same server, because root is your call to make. What it costs you is specific rather than vague: reading raw server logs, managing the firewall as root, and restarting a hung service all need root, and until you grant it those requests go to your team instead. The way we do root is the agent, where elevation is a fixed list of exact commands on your own machine rather than an open credential. With and without the agent sets the two side by side, capability by capability, and What the agent can and cannot do is the full disclosure on the agent, including what it cannot do even in the worst case.
If you choose to install the optional agent for the jobs a credential cannot reach, it is built to be unremarkable and safe to inspect: it runs under a dedicated, unprivileged account, never as root; it opens no inbound ports and makes outbound connections only; and it can only carry out the pre-approved operations. If one of your servers were ever compromised by an unrelated attacker, the agent does not hand them a catalog of what Panelbot can do elsewhere; it only ever sees the specific instructions sent to that one machine.
Instructions to your servers are scoped and encrypted
Every instruction Panelbot carries out is scoped to a specific customer and a specific machine, and it travels over an authenticated, encrypted channel. Over the panel API that means the server’s own TLS endpoint and a credential tied to that one server. Through the optional agent, every instruction is additionally cryptographically signed, and the agent checks that signature and confirms the instruction was meant for it before acting, so an instruction cannot be forged, replayed elsewhere, or redirected to a server it was not intended for.
Everything is logged
Every diagnostic Panelbot runs and every change it makes is recorded, along with who approved it and what the outcome was. You can review this trail and export it. If Panelbot ever declines to act, for example because an ownership check failed, that is recorded too, so you can see not only what happened but what was refused and why. The record is there to make the system accountable to you.
Why this design earns trust
Each of these guarantees stands without relying on the AI to cooperate. The AI cannot run anything, cannot expand what is allowed, and cannot decide who is authorized. Ownership is enforced in code, impactful changes wait for a person, the server connection is a scoped credential you can see and revoke, and the whole thing leaves a trail. Put together, that is what makes it reasonable to point a chat window at your production servers.
Where to go next
- When a human takes over explains how approvals and escalation work in practice.
- What Panelbot can and cannot do sets the honest boundaries.
- With and without the agent compares the two access levels capability by capability.
- What the agent can and cannot do is the full disclosure on the optional agent.
- How Panelbot works end to end shows the trust chain from customer to server.