An API key with the Sites permission disabled can still read site data and the .env file through the MCP server (https://ploi.io/api/mcp), so the permissions don't limit what the key can access.

Setup: custom API key with only Read permissions on Servers, Daemons, Cronjobs, Certificates, Redirects and Aliases, and "Use MCP server" enabled. Sites, Database, Firewall rules, System users, SSH keys and Auth users are unchecked. The key is used as a bearer token in an MCP client.

Steps to reproduce:

1. Create the key as described above, with Sites disabled.
2. Connect an MCP client with the key as Authorization: Bearer
3. Call the list-sites tool for a server. This returns the sites, including deploy_script and deploy_webhook_url (with token).
4. Call the get-site-env tool for a site that has a .env file.

Expected: both calls are rejected because the key has no Sites permission.

Actual: both calls succeed. list-sites returns the data, and get-site-env returns the file. I tested this with an empty .env, which returned an empty result instead of a permission error. To double check, I also tested its behavior on a site without any .env file and there it did return an error ("Could not retrieve the environment file. The site may not have a .env file, or the server is unreachable.").

Impact: keys that are meant to be read-only and limited are able to read secrets from every site in the account. The deploy_webhook_url token in list-sites can start deployments. IMHO this is baaaad.

Suggestion: make the Sites permission cover list-sites, get-site and get-site-env (and ideally a separate, explicit permission for reading .env files), and don't return deploy_webhook_url unless the key has a deploy-related permission. Related: I can't verify the permissions of an existing key in the UI (feature request filed separately: https://roadmap.ploi.io/projects/6-api-level-requests/items/1634-let-me-view-the-permissions-of-an-existing-api-key-read-only).