Provider Credentials

What it does

Provider Credentials is where you bring your own (BYO) API credentials for AI providers — OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex, Mistral, Cohere, or a custom/other provider. The control plane never sees the plaintext secret: you supply an already-encrypted ciphertext and a KMS-wrapped data-encryption key, produced by a client-side envelope-encryption step, and the console stores only that ciphertext.

The secret is never displayed or returned — anywhere, ever

There is no view or reveal action for a stored credential. After you store or rotate one, the console shows a one-time, non-secret content fingerprint (a short digest of the ciphertext, not the key) so you can verify what was saved — then it is gone from the UI for good. The table only ever shows whether a credential is “stored (encrypted)”, never a masked key or last-4 digits of the actual secret.

Configure in the UI

Models & Routing → Provider CredentialsCitadel synthetic data on a non-production Arbitex demo instance. Never client data.

1. Open Models & Routing → Provider Credentials and select Add credential.

2. Choose a Provider (OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex, Mistral, Cohere, or Custom / Other) and a Credential name (for example primary, eu-west, staging) — together these form the credential’s key.

3. Paste the Ciphertext (base64) and Wrapped DEK (base64) produced by your own envelope-encryption/KMS step — this form does not accept a raw API key. Optionally set a KMS key reference.

4. Select Store credential. A one-time dialog shows the content fingerprint — record it if you need to verify the stored value later; it will not be shown again.

5. To rotate, open the row’s Rotate action and submit a fresh ciphertext and wrapped DEK — you can leave the KMS reference blank to carry the existing one forward. To retire a credential, select Revoke and confirm; this is a governance action, not a delete — the ciphertext is never touched, but the gateway stops dispatching with it.

Test connection is honest about what it can check

The Test connection panel does not fabricate a live provider check: the control plane holds no cleartext key, so it cannot authenticate a real call by itself — that unwrapping happens at the deployment unit, where the KMS key-encryption key lives. The panel says so plainly, and will run a real reachability probe once a deployment-unit probe path is available.

API equivalent

curl -X POST "https://admin.arbitex.ai/api/v1/admin/models-routing/provider-credentials/set" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"du_id": null, "objects": [{"object_key": "openai:primary", "ciphertext_b64": "<ciphertext>", "wrapped_dek_b64": "<wrapped-dek>", "kms_key_ref": "kms://key/..."}]}'

curl -X POST "https://admin.arbitex.ai/api/v1/admin/models-routing/provider-credentials/rotate" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"du_id": null, "object_key": "openai:primary", "ciphertext_b64": "<new-ciphertext>", "wrapped_dek_b64": "<new-wrapped-dek>"}'

curl -X POST "https://admin.arbitex.ai/api/v1/admin/models-routing/provider-credentials/revoke" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"du_id": null, "object_key": "openai:primary", "reason": "rotated externally"}'

Plan & availability

Provider Credentials is available on every plan — BYO provider access is not gated by tier.

Deployment notes

On a Hybrid Outpost, the ciphertext you store here is unwrapped only at the deployment unit itself, where the KMS key-encryption key lives — never at the SaaS control plane. An air-gapped outpost needs its local KMS to be reachable for that unwrap step to succeed at request time.

Related

• Model Catalog — BYO OpenAI-compatible endpoints that use these credentials.
• Fleet & Outpost — which outposts dispatch using a given credential.