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:
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.Confirm before running
Never run
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):
Best practices
1
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.
2
Commit the permission policy
Check the
.claude/settings.json (or equivalent) into your repository so the whole team inherits the same guardrails.3
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.4
Review the deny list when the CLI updates
New mutating commands may be added over time. The verb-based deny patterns (
deploy, delete, etc.) cover most cases, but review periodically.Related
MCP Server
Connect any MCP-compatible client in read-only mode.
Qovery Agent Skill
Deploy and manage from your AI coding tool.