Permission tiers explained

Two questions, not one

There are two separate limits on what Panelbot can do to a server. The first is how much access you gave it. The second is how much impact an action carries, which decides whether it runs on its own or waits for a person. Both apply at once, so an action has to clear both. This page covers access first, then impact.

A limited panel credential. The default, and where every server starts. When your billing portal registers a server, Panelbot mints a new restricted credential on that machine rather than taking the root credential your portal already holds. A reseller credential is enough for it. It covers account and package work, DNS, mail and database checks, password resets, and suspensions, and it can do none of that outside what you granted. Nothing is installed on the server, and revoking the credential in your panel ends the access immediately. Connect a cPanel or DirectAdmin server lists exactly what the minted credential carries.

The agent, for the jobs that need root. Our recommendation when you need more. Reading raw server logs, managing the firewall as root, and restarting a hung service all require root, and the agent is how we do root: an unprivileged service on your machine whose elevated powers are a fixed list of exact commands written into a sudoers file you can read, with every run recorded. That is a bounded, inspectable, revocable form of root rather than an open one. What the agent can and cannot do is the full disclosure, and With and without the agent shows which capabilities it unlocks.

A root credential you paste in. Supported, but not what we recommend. You can hand Panelbot a root or admin credential directly and it will use it. A DirectAdmin admin credential unlocks the DirectAdmin API surface, not root work. The reason we steer away from it is that there is no allow-list in it: unlike the agent, nothing on your side of the connection constrains what that credential could be used for, so you are trusting our code rather than a boundary you can read on your own machine. It also cannot be narrowed after the fact; the only way to reduce it is to revoke it and start again. If you do use it, treat it the way you would any other root credential and rotate it when the person who created it leaves.

Not every action carries the same weight

Reading a log file is not the same as restarting a service, and restarting a service is not the same as changing something that could take a server offline. Panelbot treats them differently on purpose. Every operation it can perform is graded by how much impact it has, and that grade decides whether it runs on its own, waits for you to opt in, or requires a person to approve it.

This grading is built into each operation and cannot be talked around. The AI does not get to decide that a change is safe. The impact level is fixed when we build the operation, and the system routes it accordingly every time.

The four levels

Impact level	Example kind of action	What happens
Read-only check	Look at whether a site responds, inspect a certificate, read account usage	Runs automatically. Changes nothing.
Low-risk, reversible change	Reset a single mailbox password, clear one account’s cache	Runs only if you have turned it on. You choose automatic or approval.
Higher-impact change	Restart a service, adjust a firewall rule	Requires explicit human approval, by default someone on your team.
Most sensitive class	Changes that could break the server	Not available to the assistant at all.

Read-only checks

Most of what Panelbot does is look, not touch. Read-only checks gather the facts needed to understand a problem: is the website responding, is the certificate valid, where does the domain point, how much disk is in use. Because they change nothing, they run automatically so the assistant can diagnose quickly. There is no risk to running a check, and there is nothing to undo.

Low-risk, reversible changes

Some fixes are small, affect a single account, and can be reversed. Resetting one mailbox password is the classic example. These are off until you decide otherwise. When you enable them, you also choose how they run: automatically, so common problems resolve without waiting, or with an approval step, so a person signs off first. Either way the scope stays narrow, limited to a single account, and the change can be undone.

Higher-impact changes

Some actions reach beyond one account or touch shared parts of the system, such as restarting a service or adjusting a firewall rule. These require explicit human approval before they happen, and by default that means a person on your team weighs the change first. When Panelbot reaches this point, it pauses, tells the customer that a human has been notified, and waits for that decision.

There is one deliberate, optional exception, and you control it. A narrow class of clearly scoped destructive actions, such as deleting a specific database, removing an addon domain, deleting a mailbox, or restoring specific files or a directory the customer owns, can be allowed to complete in chat after the customer passes a strong confirmation: typing the exact name of the affected item and then confirming a final time. This path is off by default, enabling it is your choice, your team can leave it off entirely, and every action taken through it is fully logged. It exists so a customer can safely finish a clearly scoped request under guardrails you set, and it never extends to the most dangerous operations described below.

The most sensitive class

The operations that could break a server or undo an entire account, such as terminating an account or restoring an entire account from backup, are simply not part of what the assistant can do. No setting enables them in chat. They are reserved for actions your own team initiates directly, on their own authority. The AI has no path to them, so there is no scenario in which a chat conversation leads to a server-breaking or account-ending change.

A cautious start by default

New automation starts conservative. When a capability first goes live for your account, it begins in a read-only posture: it diagnoses and reports, and any change it might suggest still routes through approval before it can act. Moving a capability from careful observation to acting on its own is a deliberate step, not something that happens quietly in the background.

The same caution applies to the more powerful features in your widget settings. The option that lets the assistant complete high-impact requests in chat is off by default and turns on only through an explicit consent step, so nothing more capable switches on without you knowingly choosing it. What that setting adds is the narrow, strongly confirmed in-chat path described above, for a small class of clearly scoped actions and nothing more. Ordinary higher-impact changes still route to your team for approval, and the most dangerous operations stay off limits either way. Opting in is your decision, and you can turn it back off whenever you like.

Why grade permissions at all

You could imagine a system that just does whatever it decides is best. That system is faster right up until the day it is confidently wrong about something important. Grading by impact keeps the fast path fast, where it is safe, and puts a human in the loop exactly where the stakes are high. Automatic checks resolve the routine cases in seconds. Reversible fixes handle the common ones with a safety net you control. Anything that could genuinely hurt goes to a person.

The result is a system you can hand to your customers without wondering what it might do behind your back. The boundary between what runs on its own and what needs a human is clear, fixed in code, and visible to you.

Where to go next

Security overview: the full set of security promises in one place.
What the agent can and cannot do: full disclosure on the only part that runs on your server.
With and without the agent: which capabilities each access level reaches.
Data handling and privacy: what Panelbot stores and what it never logs.
When a human takes over: what escalation and approval look like in practice.