With the MCP server and OpsAI both able to act on your panel now, it's worth talking about API key scoping. The key picker has 50 scopes with live search and nothing preselected on purpose — you're supposed to think about what you're granting.
General rule
Start read-only. Add write scopes only for the specific task you're handing off. Reserve destructive scopes for sessions where you're actively watching what's happening.
Rough cheat-sheet
| Task | Scopes to grant |
|---|---|
| "Tell me the state of my server" |
Code:
Code:
Code:
Code:
|
| Deploying a Laravel/Node app |
Code:
Code:
Code:
Code:
|
| Debugging an issue |
Code:
Code:
Code:
|
| Full domain + SSL provisioning |
Code:
Code:
Code:
|
| Full unattended automation |
Code:
|
Why this matters for AI specifically
The MCP server tags every tool with a safety annotation — read-only, mutating, or destructive (46 tools fall in the destructive bucket, things like deleting a domain or dropping a database). A well-behaved client will prompt you before running a destructive tool. But that confirmation only protects you if the key itself doesn't already have blanket access it doesn't need. Scoping the key is your first line of defense, the client-side confirmation is the second.
Practical habit
Make a new key per use case instead of reusing one broad key everywhere. A "read-only monitoring" key for OpsAI Telegram checks, a separate "app deploy" key for Claude Code sessions where you're actively pushing code. If a key leaks or a session goes sideways, the blast radius is whatever that one key could touch — not your whole server.
*:* is there because some people genuinely want full hands-off automation and are fine with that tradeoff. Just make it a deliberate choice, not the default you reach for because the picker didn't preselect anything narrower for you.
What scopes are you actually using day to day? Curious if there's a combination we should call out as a preset.