Overview
When you let an AI agent (Claude Code, Cursor, the Qovery Agent Skill, etc.) interact with your infrastructure, you want it to investigate freely but never mutate or leak anything. Approving each generated command one by one creates decision fatigue, and a single misreadcurl or qovery api ... --method DELETE can exfiltrate data or change production state.
The classifications and the permission template on this page are a recommendation, not an absolute rule - adapt them to suit your team’s needs. In all cases, these guardrails sit on top of the permissions granted by the token used to authenticate: a command can never do more than the token allows, so a read-only token remains your strongest safeguard regardless of what the allowlist contains.
- MCP Server in read-only mode - the native, recommended option. No allowlist to maintain.
- A CLI permission allowlist - for agents driving the
qoveryCLI directly (e.g. Claude Code with the Qovery Agent Skill).
Option 1 - MCP Server (read-only)
The Qovery MCP Server is read-only by default. It can query and list resources but cannot deploy, update, or delete anything unless you explicitly opt into write mode withread_write=true.
Option 2 - CLI permission allowlist
If your agent drives theqovery CLI directly, you can constrain it at the tool-permission level. The example below is a Claude Code .claude/settings.json that you can commit to your repo and share across your team.
The policy follows three tiers:
| Tier | Meaning |
|---|---|
| allow | Read-only commands, safe to run without confirmation |
| ask | Reads that could expose sensitive data or commands that can mutate depending on flags - require confirmation |
| deny | Mutating commands and commands that return credentials/tokens in clear text - never run |
The
Bash(...:*) syntax is Claude Code’s current permission format. Other agents use their own permission files but follow the same allow / ask / deny model - adapt the command patterns accordingly.Why qovery api is in ask, not allow
qovery api is a raw passthrough to the Qovery API. It defaults to GET, but it switches to POST as soon as you pass --field or --input, and it accepts --method DELETE / PUT / PATCH. It can also reach endpoints that return secrets. Because permission patterns are glob-based (not regex with negation), there is no clean way to allow “qovery api in GET only.” The safe compromise is to ask for every qovery api call and deny the explicitly mutating method flags as a backstop.
Command reference
Safe (read-only)
These only read and display data. They never return secret values - environment-variable and secret commands return names only.| Area | Commands |
|---|---|
| Status | status, environment statuses, environment deployment list, environment deployment explain |
| Listings | <service> list, cluster list, cluster list-nodes, project list, terraform list, webhook list, webhook list-event |
| Variables (names only) | <service> env list |
| Domains / stages / registries | <service> domain list, environment stage list, container registry list |
| Logs | log |
| RDE | rde list, rde info, rde status, rde logs, rde urls, rde blueprint list, rde blueprint status |
| Meta | version, list-commands, console |
Confirm before running
| Command | Reason |
|---|---|
qovery api | Mutates when --field/--input/--method is used; can reach sensitive endpoints |
qovery shell, qovery port-forward | Interactive access - can modify container state |
qovery cluster kubeconfig | Returns a cluster access token |
qovery env import, qovery env parse | Reads/writes variable values (including secrets) locally |
curl, wget | Raw HTTP - can exfiltrate to arbitrary domains |
Never run
| Command | Reason |
|---|---|
qovery token, qovery auth token | Print an API/access token in clear text |
deploy, redeploy, stop, cancel, delete, update, create, clone, edit (any service) | Mutate platform state |
cluster install / upgrade / lock / unlock | Mutate cluster state |
<service> env create / update / delete / alias / override | Mutate variables and secrets |
terraform plan-and-apply / delete / force-unlock / migrate-state | Mutate infrastructure and Terraform state |
rde create / delete / stop / upgrade, rde blueprint deploy | Mutate RDE state |
API endpoints that return secrets
Even though they areGET requests, these endpoints return credentials in clear text. Block them in any read-only setup (they are covered by the qovery api rules above, but list them explicitly if you allow curl):
| Endpoint | Exposes |
|---|---|
GET /database/{databaseId}/masterCredentials | Database master password |
GET /organization/{organizationId}/{aws,gcp,scaleway,onPremise}/credentials | Cloud provider credentials |
GET /organization/{organizationId}/cluster/{clusterId}/cloudProviderInfo | Cloud provider credentials |
GET /cluster/{clusterId}/token | Cluster token |
GET /cluster/{clusterId}/argoCdConfig | ArgoCD token |
Best practices
Prefer read-only mode end to end
Use the MCP Server in its default read-only mode, and/or back the agent with a read-only API token created in Settings > API Tokens.
Commit the permission policy
Check the
.claude/settings.json (or equivalent) into your repository so the whole team inherits the same guardrails.Keep secrets out of logs
qovery log is safe to allow, but logs reflect whatever your application writes. Avoid logging PII or credentials in the first place.Related
MCP Server
Connect any MCP-compatible client in read-only mode.
Qovery Agent Skill
Deploy and manage from your AI coding tool.