A model provider key grants the access allowed by its account, project, and permissions. Keep it separate from the Gateway secret and channel tokens, then limit where each credential can be read or used.
Independent guide. OpenClaw secret and sandbox references reviewed on October 2, 2026. No tool sandbox, spending setting, or checklist is presented as a guarantee against compromise or billing overrun.
Keep credentials out of agent output
Do not ask the assistant to dump its environment, print keys, or copy a credential-bearing config into chat. Tool output can become part of model context and conversation transcripts. Logs, screenshots, repositories, Docker image layers, and backups are also possible exposure paths.
Use the official secrets reference for supported storage and resolution. Whether a particular secret reference is valid depends on its config path and installed version; a reference is not a universal substitute for every credential field.
Inspect the assistant's actual access
openclaw config validate
openclaw sandbox explain
Follow the official sandbox guide and review mounts, environment injection, elevated execution, and plugin access. Sandboxing reduces access according to the effective policy; it does not guarantee that a key is absent from all tools, integrations, or model-visible output.
Test boundaries with harmless marker files. Do not use a real credential as the test data. The sandboxing guide describes the difference between the Gateway container and the tool sandbox.
Separate credentials by responsibility
Use separate provider credentials for different deployments where the provider supports that arrangement. Prefer the smallest permissions suitable for the task. Keep Gateway authentication enabled and review channel allowlists and pairing independently.
Follow the official security guide when choosing remote access. For a personal VPS, private SSH or Tailscale access can reduce public exposure. Docker port publication must still be reviewed; an SSH tunnel does not close an already public listener.
Verify spending controls instead of assuming a hard cap
A budget notification, enforced usage limit, account balance, and per-key allowance are different controls. Check your provider's current dashboard and documentation for:
- Whether the setting only sends alerts or actually rejects further requests.
- Whether its scope is the organization, project, account, or individual key.
- Reset time, reporting delays, and treatment of in-flight usage.
- Whether the API credential used by OpenClaw belongs to that scope.
For OpenAI, start with project and spending controls. Do not assume every setting labelled “budget” is enforced. If your provider supports an enforced limit, explicitly configure and verify that behavior; keep alerts and usage review as additional controls.
A spending limit is not a credential-security boundary, and it does not make a leaked key a harmless event. Unauthorized use can affect data or account access as well as cost.
Review skills and plugins before granting access
Read the source and requested permissions for third-party instructions or code. A marketplace listing, popularity claim, or familiar skill name is not a security audit. Test new integrations using disposable data and review the skills checklist.
Keep keys out of container image builds and public version history. Store backups privately and review their contents; backups can preserve credentials alongside state. Use the official backup reference when choosing what to archive.
Respond to an exposed credential
- Revoke the exposed credential using the issuer's documented procedure.
- Check the issuer's available usage and access records; do not assume every request has a complete retained transcript.
- Identify the exposure path and stop it before adding a replacement credential.
- Rotate other credentials that were exposed through the same path, following each channel or provider's procedure.
- Configure the replacement's available permissions and spending controls, then verify the assistant's model and channel access.
Revocation may have propagation or in-flight effects depending on the issuer. Keep monitoring after revocation. A new key placed in the same exposed file or prompt repeats the problem.
FAQ
Can the assistant see a provider key?
That depends on the secret setup, tools, plugin execution, mounts, and environment. Avoid printing it and inspect the actual access policy; a software version number alone cannot answer this for your deployment.
Does a budget alert stop a stolen key?
An alert is a notification. Use the provider's documented enforced controls where available and verify their scope. Revoke an exposed credential regardless of the budget setting.
Should I share diagnostic logs for help?
Share only the relevant redacted error, version, and installation method. Remove credentials, account identifiers, and private messages first. See the CLI guide for diagnostic commands.