Skip to main content

Safety best practices

An AI agent should not decide how much production access it gets. You should.

Quave ONE authorization is deterministic. Every MCP request is checked by the server against the OAuth grant or MCP key, the user's account and environment access, and the rules for that specific tool. The agent cannot use a prompt to bypass those checks.

Production safety is not a better prompt. It is a smaller credential.

Choose access in this order​

  1. Start with Read Only for investigation, monitoring, and support.
  2. Use By tools when the agent has a small, known job.
  3. Use By permissions only when a trusted agent truly needs a broader set of tools that may change over time.

In tool mode, Quave ONE exposes and accepts only the tools you selected. New tools are not added automatically.

Avoid dangerous permissions​

Do not grant Write Dangerous (quave:write:dangerous) to a normal agent. It covers destructive actions such as stopping or rolling back environments, removing hostnames, deleting resources, and cleaning up backup data.

Do not grant Control Destroy Protection (quave:admin:destroy-protection) either. This permission can disable the lock that protects an environment from deletion.

If an agent really needs one dangerous action, use By tools and select that exact tool, plus only the read tools it needs to make the decision. For example, an agent that can roll back a deployment does not also need permission to delete the environment.

The selected action is still dangerous, but the possible damage is much smaller. Confirmation prompts help, but they do not fix an overpowered credential.

Lock production against deletion​

Open the production environment, select Settings, and enable Prevent destroy. It blocks deletion of that environment and also blocks deleting its parent app or account.

The agent operating production can have enable-app-env-prevent-destroy to apply this safety lock. Do not grant it disable-app-env-prevent-destroy or the Control Destroy Protection permission, because either can remove the same lock that is meant to stop it.

Prevent destroy blocks deletion, not every risky change. An agent may still be able to stop, roll back, deploy, or reconfigure an environment if you grant those tools.

Give every agent its own access​

  • Prefer OAuth when the client supports it. Otherwise, create a dedicated MCP key for that agent and purpose.
  • Do not reuse a personal admin credential across agents.
  • Do not put OAuth tokens, MCP keys, or secrets in prompts or logs.
  • Disable the key or revoke the connected app as soon as it is no longer needed.
  • Grant Manage MCP Keys only to an agent that really manages keys. A limited MCP key cannot create or manage a key with more effective access than its own.

Use the Audit Log to review MCP actions. Quave ONE records the actor, channel, action, and affected resources, so separate credentials make incidents easier to understand and contain.

Before you connect an agent to production​

  • The agent has its own OAuth grant or MCP key.
  • It starts read-only or uses an explicit tool allowlist.
  • It does not have Write Dangerous.
  • It cannot change Prevent destroy.
  • Prevent destroy is enabled on every production environment.
  • You know how to disable or revoke the credential immediately.

Some dangerous workflows have extra safeguards, such as a required cleanup preview or retained database volumes after environment deletion. They can help with recovery, but they are not a reason to grant more access.

See Security and authorization for the complete authorization model and Available MCP tools for the current tool catalog.