Documentation · AI

AI providers

Warden’s AI foundation keeps provider configuration separate from credentials, supports one shared instance credential for simple installs, and lets individual Warden accounts override it when separate billing or quotas are preferred.

Credential resolution

Warden account starts an AI task
  → account-specific provider credential, when configured
  → otherwise shared instance credential
  → otherwise provider unavailable

Credentials are stored in Warden’s encrypted secrets.json; plaintext keys are never returned to the browser after saving. Administrators can include them in a password-encrypted portable Warden backup when migrating or reinstalling an instance.

Simple and individual setups

A personal or small trusted installation can configure one provider key once and let every permitted Warden account use it. A user can later add a personal key for the same provider without changing the shared configuration.

Provider defaults such as base URL and default model live in ai.json. Remote HTTP endpoints are rejected; plain HTTP is allowed only for loopback services such as local Ollama.

Usage attribution

Usage accounting belongs to the Warden account that launched the task, not to the credential. That means shared API keys remain convenient without losing per-account request/token/cost reporting. Users see their own totals in System → AI providers; accounts with ai.manage also see usage broken down by Warden account so a shared credential can still be accounted for. Aggregates are stored in ai-usage.json ready for the coding agent to record real provider usage.

Access control

ai.use allows an account to use configured providers. ai.credentials separately controls whether that account may store and use a personal credential override. Administrators can therefore require company/shared credentials while still allowing the coding agent. ai.manage controls shared provider configuration and shared credentials. If ai.credentials is removed, any previously stored personal key remains encrypted but is ignored until permission is restored.

Credential and output boundaries

Personal credentials take precedence only while the account retains ai.credentials; otherwise Warden ignores them and falls back to an available shared credential. Plaintext credentials are injected into a private subprocess environment and are never returned by settings or status APIs. Provider diagnostics and structured events are redacted and bounded, but operators should still treat provider output as hostile content rather than trusted system evidence.

Warden Agent

Warden Agent now uses this provider layer directly. OpenCode Zen, OpenRouter, OpenAI, Anthropic, Google Gemini and DeepSeek use Warden-managed account/shared credentials; Ollama can run locally without a key. Each Agent session chooses its provider independently and uses that provider’s configured default model. See Coding agent.

Built-in provider updates

When Warden introduces a new built-in AI provider, existing installations merge that provider into their editable ai.json automatically at startup. Existing provider settings and custom providers are preserved.