Security overview

Security you can check, not just trust

Giving anything access to a production server is a decision you should be able to defend to your team. This page lays out exactly what Panelbot can and cannot do on your machines, and how each promise is enforced. Every claim here is a property of the design, not a policy we ask you to take on faith.

The short version: the AI talks to your customers, but it never touches your servers. Actions are limited to a fixed, pre-approved set. Ownership is verified in code before anything runs. By default nothing is installed on your server: Panelbot connects over the panel API with a scoped credential you can see, limit, and revoke, and it shows you what that credential can and cannot reach.

The AI never runs anything

The assistant that chats with your customer has one job: read what the person wrote and turn it into a plain-language reply. It reads the message, pulls out the relevant details, and words the response. That is the entire scope of its authority.

It does not choose which action to take, pick which server to touch, or decide whether a customer is allowed to do something. Those decisions are made by code, following rules you control. If the AI ever produces a request that falls outside what the current situation allows, the request is refused before it reaches your server. We do not rely on instructing the AI to behave. We enforce the boundary in code, every time.

This is the difference between Panelbot and a chatbot wired directly to a command line. The assistant is a translator between your customer and a system that has its own, independent rules about what may happen.

Only pre-approved operations

Panelbot can run only a fixed set of allow-listed operations that we build, test, and maintain. It has no ability to run arbitrary commands, open a shell, or improvise a new action on the fly. Each operation does one well-defined thing, and the full set is grouped by what it achieves for the customer: checking email delivery, inspecting a website that is down, looking at an SSL certificate, and so on.

If an issue needs something outside that set, Panelbot does not attempt a workaround. It hands the conversation to a human on your team. Nothing new can run on your server without going through our normal build and release process, which means you always know the ceiling of what is possible.

Ownership is checked in code

Before Panelbot inspects or changes anything, it confirms in code that the customer actually owns the domain or account in question. This check reads from the service records synced from your billing portal, not from anything the customer typed and not from anything the AI concluded.

If a customer mentions a domain that is not on their account, Panelbot refuses to act on it, regardless of how the request is phrased. Ownership and authorization are never decisions the AI is allowed to make. This is what keeps one customer from reaching another customer’s site, even by accident.

A connection that stays in its lane

Panelbot reaches your server through the panel’s own API, using a credential you grant: a WHM API token on cPanel, a login key on DirectAdmin. A reseller credential is enough. The credential decides the ceiling, and when the server connects Panelbot checks that ceiling and shows it to you as a plain list of what it can and cannot do on that machine. Whatever you grant, it never sees your billing through the server, never changes your root or admin password, and never reads customer passwords. Revoking the credential on the panel side ends the access instantly.

The connector that registers a server from your billing portal is plain code in your own portal, and you can read it. No real key or credential is ever displayed in the Panelbot dashboard.

We take the limited credential even when your billing portal holds root for that server, because root on your machines is your decision rather than ours to assume. The trade is real and we would rather show it than hide it: a limited credential cannot read raw server logs, manage the firewall as root, or restart a hung service. When you want those, the agent is how we do root, as a fixed list of exact commands rather than an open door. With and without the agent is the capability-by-capability comparison, and What the agent can and cannot do is the full disclosure on the agent itself, including what it still cannot do if Panelbot were compromised.

If you choose the optional agent for jobs a credential cannot reach, it is a small, unprivileged service. It runs under a dedicated system account, not as an administrator. It opens no inbound network ports, so there is nothing new on your server for an outsider to connect to or attack. It reaches out to Panelbot rather than waiting to be reached, runs only the pre-approved operations, and takes instructions only from your own Panelbot account. You are free to inspect it, update it, or remove it at any time.

Encrypted in transit and at rest

Every instruction Panelbot carries out is scoped to your account and a specific server, and it travels over an authenticated, encrypted channel. Instructions to the optional agent are additionally cryptographically signed, so they cannot be forged, replayed against the wrong server, or redirected to another customer.

Sensitive stored values, such as the credentials for your billing portal and the panel credential for each server, are encrypted at rest and decrypted only at the moment they are used. Secrets are never written to logs, never echoed back in responses, and never included in error messages.

Graded permissions, humans in charge of risk

Not every action carries the same weight, so Panelbot grades them by impact. Read-only checks that change nothing run automatically. Low-risk, reversible changes run only if you have turned them on. Higher-impact changes require explicit human approval, by default a person on your team. One optional setting you control lets a narrow, clearly scoped class of destructive actions, such as deleting a database or removing an addon domain, complete in chat after the customer passes a strong confirmation; it is off by default and fully logged. The most dangerous class of operation, such as terminating an account or restoring an entire account from backup, is never available to the AI at all.

When Panelbot is unsure, when a change is risky, when the problem is outside its scope, or when the customer simply asks for a person, a real person on your team takes over and the assistant steps back. See permission tiers explained for the full breakdown, and when a human takes over for how handoff works.

A record of everything

Every diagnostic check and every change is recorded, along with every approval decision. Requests that Panelbot declined are recorded too, so you can see not only what happened but what was prevented. You can review this trail in your dashboard and export it whenever you need it.

Where to go next

• Data handling and privacy: what we store, what we deliberately do not, and your export and deletion rights.
• Permission tiers explained: the three ways to connect, and how automatic checks, opt-in fixes, and human-approved changes are separated.
• What the agent can and cannot do: the full account of the only component that runs on your server.
• With and without the agent: what each access level reaches, capability by capability.
• Safety and permissions: the trust model in context.