Should You Bring Your Own AI Provider Keys?

DAVE supports seven provider types. Each maps to a category of AI service, not a single model. You can configure multiple providers of the same type: for example, one OpenAI provider for production and a separate one for staging, each with its own API key and model catalog.

The seven provider types, with their default base URIs where applicable:

• OpenAIdefault base URI https://api.openai.com/v1. Supports model fetch from the API.
• Anthropicdefault base URI https://api.anthropic.com/v1. Supports model fetch from the API.
• Azure OpenAIyou supply your Azure deployment endpoint. Supports model fetch. Because Azure OpenAI endpoints are deployment-specific, the help documentation recommends including the deployment name in the provider Name field for clarity, for example: "Azure OpenAI - eastus2 gpt-4o".
• Google AIdefault base URI https://generativelanguage.googleapis.com/v1beta. Supports model fetch from the API.
• OpenAI-Compatibleyou supply the endpoint. Supports model fetch. Use this type for any service that implements the OpenAI API interface, including third-party providers and hosted inference endpoints.
• Local (Ollama)default base URI http://localhost:11434/v1. Supports model fetch. Use this type to point an agent at a locally running Ollama instance. Note: this is model hosting on your own machine, not DAVE product hosting. DAVE itself is fully managed and hosted by voolama LLC.
• Customyou supply the endpoint and the model catalog manually using the JSON editor. Model fetch is not available for Custom providers.

For all types except Custom, DAVE can fetch the available model list directly from the AI service after you enter a valid API key. This is the recommended approach: it avoids typos in model IDs and ensures you see the latest available models from your account.

When you enter an API key into a provider record, DAVE stores it encrypted in a per-tenant credential vault using AES-256-GCM authenticated encryption. The key is masked by default in the UI: you can click the eye icon to reveal it temporarily, but it is never returned through the API once stored. If you need to rotate a key, you edit the provider record and enter the new value; the old value is overwritten and the new one is encrypted at rest.

Keys are transmitted only over HTTPS and are never logged in plain text. The provider list page at Admin → API Management → Providers is restricted to the Admin role. No other default role can view, create, edit, delete, or fetch models from a provider record. This means your API keys are visible only to users you have explicitly granted Admin access.

The practical implication of centralized, encrypted storage is key rotation. Because all agents that use a provider reference the same provider record, rotating an API key means editing one record, not updating every agent individually. A compromised key can be replaced in a single operation, and every workflow that references that provider immediately uses the new key on its next execution.

DAVE ships with six default tenant roles: Admin, Create, Curate, Use, Reporting, and Financial. All roles are editable by your administrator. Only Admin has access to the Providers page.

Provider configuration lives at Admin → API Management → Providers. The page shows a card for each configured provider. To add a new one:

1. Click Add Provider in the top-right corner. The create form appears above the provider list.
2. Enter a Name. Use a descriptive label that identifies the service, environment, and purpose: "OpenAI Production", "Anthropic Dev", or "Azure OpenAI - eastus2 gpt-4o". This name appears in agent configuration dropdowns, so clarity here saves confusion later.
3. Select a Provider Type from the dropdown. For OpenAI, Anthropic, Google AI, and Local (Ollama), the Base URI field auto-fills with the service default endpoint. For Azure OpenAI, OpenAI-Compatible, and Custom, you enter the endpoint manually.
4. Enter your API Key. The field is masked by default.
5. Configure the Model Catalog. For all types except Custom, click Fetch Models to retrieve the available model list from the service. Use the search box to filter, then check the models you want to include. For Custom providers, switch to JSON mode and paste a model array.
6. Click Create Provider. The provider card appears in the list.

After creating a provider, use Fetch Models to verify that the API key and base URI are correct. A successful fetch confirms the provider can reach the AI service. If the fetch fails, check that the API key is valid, the base URI matches the service expected endpoint, and the key has permission to list models.

Once a provider is saved, it becomes available in the agent configuration dropdown. When you configure an agent, you select a provider and a model from that provider catalog. The agent uses the provider API key and base URI at runtime to call the AI service. The provider record is the only place those credentials live.

Most teams end up with more than one provider record, even if they only use one AI service. Common patterns:

Production and staging separation

Configure separate provider records for production and staging environments, each with its own API key. This keeps your production usage quota separate from test traffic, and means a staging key compromise does not affect production. Name them clearly: "OpenAI Production" and "OpenAI Staging" are unambiguous in the agent configuration dropdown.

Multiple services for different use cases

Different AI models have different strengths. You might route content generation agents through one provider and classification or review agents through another. Because DAVE supports all seven provider types simultaneously, you can configure an Anthropic provider for tasks where Claude performs best and an OpenAI provider for tasks where GPT models are the better fit, and assign each agent to the appropriate provider without any workflow-level complexity.

Spreading load across providers

If a single provider rate limit is a bottleneck, you can configure multiple provider records pointing to the same service with different API keys. Assign different agents to different providers to distribute request volume. This is a manual load distribution pattern: DAVE does not automatically balance across providers, but the agent-level assignment gives you explicit control over which key handles which workload.

Keeping the model catalog curated

Only include models your team actually uses. A smaller catalog makes model selection in agent configuration faster and less error-prone. When a provider available models change, use Fetch Models to refresh the catalog and update your selections. For Azure OpenAI, ensure at least one model is deployed in your Azure resource before fetching, or the fetch will return an empty catalog.

Before deleting a provider

Before deleting a provider record, update all agents that reference it to point to a different provider. If you delete a provider while agents still reference it, those agents will fail on their next invocation. Check active agent assignments before deletion.

The bring-your-own-keys model is a deliberate architectural choice, not a missing feature. Here is what it gives you that a proxied or bundled AI access model does not.

Your usage, your data agreements

When your agents call an AI provider using your key, your organization data handling agreement with that provider applies directly. You are not routing sensitive content through an intermediary whose data handling terms you may not have reviewed. For teams in regulated industries, or teams with strict data residency requirements, this matters. The AI provider you choose, and the terms you have agreed to with them, govern what happens to the content your agents process.

Your rate limits, your capacity planning

Your API key carries your account rate limits and usage quotas. You can see your usage on the provider own dashboard (OpenAI Usage, Anthropic Console, and so on), set spending limits, and upgrade your plan independently of DAVE. There is no shared pool, no usage cap imposed by the platform, and no margin added to your AI spend.

Your key rotation schedule

Security best practice is to rotate API keys regularly. Because DAVE centralizes key storage in provider records, rotation is a single-record operation. Update the key in the provider record, and every agent that references that provider uses the new key immediately. You control the rotation schedule and the process without coordinating with a third party.

Model flexibility without platform lock-in

When a new model releases, you add it to your provider catalog and update your agent configuration. You are not waiting for a platform update to expose a new model. When a model is deprecated, you update the agent to use a replacement. The seven provider types cover the major AI services and the OpenAI-Compatible type covers a wide range of third-party and hosted inference endpoints, so the model landscape is yours to navigate on your own timeline.