# AI token recipes

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](/developers/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.