AI token recipes
Four ready scope sets for AI tokens, with the risks that remain and recommended limits.
Pick the smallest recipe that does the job. You can always make a bigger token later; you cannot undo a leak. Names of scopes are explained in Scopes and permissions.
Recommended settings for all recipes: an expiry (see each recipe), allowed IP addresses when the agent runs from a fixed place, limits to only the servers and sites needed, a token name that says what it is for (for example claude-monitor), and one token per tool.
Recipe 1: Monitor only
The AI can look but not touch.
| Scopes | servers:read, sites:read, deployments:read, backups:read |
|---|---|
| Works over MCP | whoami, list_servers, get_server, get_server_health, get_server_security, list_server_certificates, list_sites, get_site, get_site_certificate, list_deployments, get_deployment, list_site_backups |
| Expiry | 30 days |
| Limits | None needed, or the servers you want watched |
Remaining risks: it can read server names, addresses, domains, commit messages and deployment logs. Deployment logs and commit messages can contain text written by others, but a read-only token cannot act on it.
Recipe 2: Deployer
The AI can deploy, roll back and renew certificates for chosen sites.
| Scopes | Recipe 1 plus deployments:write, certificates:renew |
|---|---|
| Works over MCP | Recipe 1 tools plus deploy_site, rollback_site, renew_certificate |
| Expiry | 7 days |
| Limits | Only the sites it should deploy (for example staging). Allowed IPs. |
Remaining risks: a bad deploy, or a deploy of malicious code that someone pushed. The code scan runs first and stops serious findings. A rollback cannot undo database changes. Tell the AI to ask before deploying production.
Recipe 3: Site builder
The AI can create and configure sites, DNS, and back up. No secrets.
| Scopes | Recipe 2 plus sites:write, dns:read, dns:write, backups:write |
|---|---|
| Works over MCP | Same as recipe 2 plus back_up_site. Creating sites needs the REST API. |
| Expiry | 3 days |
| Limits | One or two servers. Allowed IPs. |
Remaining risks: sites:write can change Nginx settings (custom_nginx), build scripts that run on deploy, services and scheduled jobs. A build script runs code on your server at deploy time. Read what the AI sets. backups:write includes restoring a database, which replaces data: make the AI ask first. dns:write only adds missing A records.
Recipe 4: Full operator
For a trusted agent that runs your infrastructure with you watching.
| Scopes | Recipe 3 plus servers:write, logs:read |
|---|---|
| Not included | env:read, env:write, commands:run, team:write. Add them only for a short, supervised session. |
| Expiry | 1 day, renewed by you |
| Limits | The specific servers and sites. Allowed IPs always. |
Remaining risks: servers:write can open firewall ports, install packages and PHP, restart services, reboot, and run security fixes. Logs can contain secrets and injected text. It still cannot delete anything.
If you add deletions:request, the AI can propose deletions. A human still approves.
Which scopes to avoid giving to an AI
| Scope | Why |
|---|---|
env:read |
Exposes passwords and API keys to the AI provider's servers. |
env:write |
An injected instruction could change app secrets. |
commands:run |
Arbitrary code on your server. |
team:write |
Lets it invite people. |
deletions:request |
Not dangerous alone, but increases what you must review. |
Team owner's controls
The owner can cap everything: API, then Rules sets which scopes tokens may get, who may make tokens, the longest life, and whether IP addresses are required. Set the rules so that even a careless member cannot make a "Full operator" token.