Skip to main content
By default, Cyberdesk runs models with its own provider credentials. With BYOK, your organization can supply its own credentials per provider, so model usage for that provider is billed to your provider account.

​
Provider slots

Each credential covers one provider slot: Custom model configurations that carry their own API key keep using that key.

​
How slots behave

  • Slots you never configure keep using Cyberdesk keys.
  • Once you add a key for a slot, Cyberdesk stops using its own key for that provider, permanently. Every run that uses a model on that provider uses your credential, including fallback models, cache detection, extraction, output transformation, and post-run checks.
  • Deleting a key does not switch the slot back to Cyberdesk keys. The slot shows Missing and runs that need that provider fail until you add a new key. Contact Cyberdesk support if you want a slot returned to Cyberdesk keys.

​
Failures

  • Before a run touches the desktop, Cyberdesk checks that every model the run will call has a usable credential. If a required slot is missing or invalid, the run fails immediately with an error naming the provider.
  • If a provider rejects your credential during a run (HTTP 401/403 or the provider’s equivalent), the run fails, the key is marked Invalid, and Cyberdesk does not fall back to its own keys.
  • Rate limits (429) and provider server errors (5xx) still trigger the normal fallback models. Fallback models whose slot is missing or invalid are skipped.

​
Managing keys

Organization admins manage keys from the dashboard home page under BYOK API keys, or through the API (GET /v1/provider-credentials, PUT/DELETE /v1/provider-credentials/{slot}, POST /v1/provider-credentials/{slot}/validate). Secrets are stored in a vault and are never returned by the API; the dashboard only shows non-secret details such as the last four characters, project ID, service account email, and region. Validate makes a minimal live call with the stored credential. For Google it checks each location Cyberdesk’s default models use (for example Gemini on global and Claude on Vertex AI in us-east5) and reports each result separately.

​
Google Cloud setup

  1. Enable the Vertex AI API on the project.
  2. Grant the service account the Vertex AI User role (roles/aiplatform.user).
  3. Enable Anthropic Claude models in Vertex AI Model Garden (needed for Claude on Vertex).

​
AWS Bedrock setup

  1. Enable model access for Anthropic Claude models in the Amazon Bedrock console. First-time Anthropic use requires submitting the use-case form.
  2. Give the IAM identity bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream (Converse uses these).
  3. Make sure cross-region inference profiles (us. models) are available from the region you choose.