Giving an AI access to your server is safe when that access is scoped, signed and clearly labeled by risk — and Panelica's MCP integration is built around exactly those three controls. An API key grants only the specific permissions you select, every request is authenticated with HMAC-SHA256, and every one of the 404 available tools is marked read-only, mutating or destructive so a client can warn you before anything irreversible happens.
The real question is not "AI or not," it is "how scoped"
Every access method to a server carries risk — an SSH key with no passphrase, an API token with no expiry, a support engineer with root and no audit log. The right question for AI access is the same one you would ask about any of those: what exactly can this credential do, is that the minimum needed, and is there a record of what it actually did. Answer those three well and "an AI is involved" stops being the interesting variable.
Control 1: 50 scoped permissions, nothing preselected
When you generate an API key in Panelica for MCP use, it starts with zero permissions. You search across 50 distinct scopes — covering accounts, domains, databases, DNS, email, FTP, SSL, backups, files, Cloudflare, Docker, apps, Git, logs, security and server management, each with granular read, write and delete permissions — and add only what the task in front of you actually requires. A key intended for an AI assistant that reads logs and restarts a stuck application needs read access to logs and write access to services; it does not need delete access to backups or write access to DNS. Nothing forces you to grant more than that, and nothing is granted by default.
Control 2: signed requests, secrets that never leave your machine
Every request the MCP server makes to your panel's External API is signed with HMAC-SHA256 using the API secret you generated. The secret itself is never transmitted with the request and never sent anywhere except your own panel — it lives in your MCP client's environment configuration, not in a third-party service. The MCP server itself collects no telemetry about what it does or what server it is connected to; there is no vendor-side log of your infrastructure to worry about leaking.
Control 3: every tool tells you how dangerous it is before it runs
Across the 404 tools in the Panelica MCP catalogue, 181 are read-only, 177 are mutating, and 46 are destructive — and every tool carries that classification as a first-class annotation, not something buried in documentation. MCP clients that respect these annotations use them to decide when to ask for explicit confirmation before executing a call. A tool that lists domains runs without friction; a tool that deletes a database is flagged as destructive so the client can put a human in the loop first.
| Annotation | Example tools | What it means in practice |
|---|---|---|
| Read-only | list domains, get SSL status, tail logs | Safe to run without confirmation; cannot change server state |
| Mutating | create database, deploy application, restart service | Changes state but is generally reversible or expected as routine |
| Destructive | delete domain, drop database, remove backup | Irreversible or high-impact; clients should confirm before executing |
Practical scoping patterns
- Investigation-only key — read access to logs, services, domains and security, nothing else. Safe to hand to any AI client for diagnosis without risk of it changing anything.
- Deploy key — write access to Git, application hosting and logs, but no access to domains, DNS or backups. Scoped to what a CI-adjacent AI workflow actually needs.
- Full operations key — broader write access for a trusted embedded agent like OpsAI, used from a controlled environment such as the panel's own desktop or a private Telegram group, described in Manage Your Server from Telegram: The OpsAI Agent Explained.
Keys can be revoked or re-scoped at any time from Developer > API Keys, and a session using a revoked key fails its next request immediately — there is no lingering access.
What this does not protect against
Scoping protects against an AI doing something outside its intended boundary; it does not substitute for reviewing what you are asking it to do in the first place. If a key has delete access to backups because the task genuinely needs it, a destructive-labeled call inside that scope will still execute if the client is configured to proceed without confirmation. The controls here are about minimizing blast radius and making risk visible — not eliminating the need to think about what you are authorizing.
How this compares to handing someone SSH access
An SSH key with shell access is effectively unscoped — whoever holds it can do almost anything the underlying user can do, and there is no per-action risk label at all. A Panelica MCP API key is narrower by construction: it is limited to the 406 endpoints of the External API, each gated by its own permission scope, with every call individually labeled by risk. In that comparison, well-scoped AI access is not the riskier option.
Get started safely
Generate a properly scoped key before connecting any AI client. Start narrow, expand only as needed, and review the destructive-tool list before trusting a session with broad write access. Learn how to connect a client in How to Manage a Web Server with Claude Code. Source and details: github.com/Panelica/panelica-mcp.