Provider auth
Understand the planned provider auth workflow and how it is intended to simplify credential management across runtimes.
Provider auth is not currently available for general use. This page explains the planned workflow so teams understand what the feature is for and how it will fit into ClawControl. Availability is currently controlled and may not appear in every workspace even during early rollout.
What provider auth is meant to solve
Today, provider credentials are managed directly in the OpenClaw environment on the runtime host.
Provider auth is intended to make that easier by giving ClawControl a structured way to:
- store workspace-level provider credentials
- validate whether those credentials are usable
- attach them to the right runtime
- sync the right credentials to the right host
What the future workflow is designed to look like
The planned experience is centered around the Providers area in settings.
At a high level, teams will be able to:
- add provider credentials for a workspace
- support different provider auth methods, such as API keys and selected OAuth flows
- attach a provider credential to a runtime
- test whether a credential is working
- retry sync when a runtime needs the credential reapplied
Planned launch support
The current launch catalog in the product contracts includes the following providers and auth modes:
| Provider | Auth type at launch | Account type or credential model | Notes |
|---|---|---|---|
| Anthropic | API key | Anthropic API account | Intended for Claude model access |
| OpenAI | API key | OpenAI API account | Intended for GPT model access |
| OpenAI Codex | OAuth | ChatGPT / Codex plan | Planned OAuth connection for subscription-based access |
| Google AI | API key | Google AI API account | Intended for Gemini model access |
| OpenRouter | API key | OpenRouter account | Intended for routed model access |
At launch, the only planned OAuth-based provider in the current catalog is OpenAI Codex. The other planned launch providers use API-key authentication.
Why this matters
As teams add more runtimes and more agents, local credential setup becomes harder to manage consistently. Provider auth is meant to reduce that overhead and give operators better visibility into what is connected where.
What will stay the same
Even after provider auth is available, ClawControl will still be coordinating credential usage rather than bundling model access itself.
In practical terms:
- teams will still use their own AI provider accounts
- model usage will still depend on those provider accounts
- ClawControl will help manage the operational side of attaching and syncing credentials
What to do today
Until provider auth is available, manage provider authentication directly in your OpenClaw environment on the runtime host.
For example, the runtime setup flow still depends on the local OpenClaw side having usable auth profiles when agents need provider access.