API Key Management: Building a Central Vault for Multiple AI Providers

When you work with one AI provider and one project, API key management is simple: put the key in .env.local, do not commit it, done.

When you work with four projects, six AI providers, and an autonomous agent system that needs to switch providers based on task type, it becomes an active problem.

Here is the vault I built to solve it.

The Problem With Per-Project Key Management

Four projects × six providers = 24 API keys to track, rotate, and audit. Hardcoding them per project means:

• —Rotating one provider's key requires updating four .env.local files (and Vercel environment variables)
• —An agent system that routes tasks to different providers needs to know which key to use at runtime, not at build time
• —There is no audit trail of which key was used for which operation
• —There is no way to see spending across providers in one view

A central key vault solves all of these.

The Database Schema

CREATE TABLE agent_api_keys (
  id BIGSERIAL PRIMARY KEY,
  provider TEXT NOT NULL
    CHECK (provider IN ('anthropic','openai','deepseek','groq','gemini','mistral','openrouter')),
  api_key TEXT NOT NULL,
  label TEXT,
  is_active BOOLEAN DEFAULT TRUE,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  last_used_at TIMESTAMPTZ,
  usage_count INT DEFAULT 0,
  UNIQUE (provider, label)
);

Each row is one key for one provider. The label field allows multiple keys per provider (useful for separating personal and client project usage). The is_active flag lets you disable a key without deleting it — important for rotation.

Security Basics

The agent_api_keys table has RLS policies that allow only authenticated admin users to read or write. The anon key cannot access it. The API keys are stored in the database as plaintext — this is a pragmatic choice for a single-user admin panel, but for multi-user or shared infrastructure, encryption at rest using Supabase Vault (which uses pgcrypto) is the right approach.

Critically: the keys are only ever read server-side. The admin panel fetches the key list with key values truncated (showing only the last 4 characters) for display. The full key value is fetched from a server-side function only when the agent runner needs it. The key never appears in a client-side network request.

Runtime Key Selection

The agent runner selects the key at runtime based on the agent's provider config:

async function getApiKey(provider: string): Promise<string> {
  const { data } = await supabase
    .from('agent_api_keys')
    .select('api_key')
    .eq('provider', provider)
    .eq('is_active', true)
    .order('last_used_at', { ascending: true }) // rotate through keys
    .limit(1)
    .single();

  if (!data) throw new Error(`No active key for provider: ${provider}`);
  return data.api_key;
}

The key is resolved at the start of each agent run. Rotating a key means inserting a new row, marking the old row as inactive. No code deployment required.

The Admin UI

The settings page shows:

• —Provider name
• —Key label
• —Last 4 characters of the key value (truncated)
• —Active/inactive status
• —Last used timestamp
• —Usage count

Adding a key: a form with provider selector, label, and key input. The form submits to an API route that inserts the row server-side.

Rotating a key: deactivate the old key, add the new key. The agent runner picks up the new key on the next run.

What This Unlocks

Beyond key management, the vault enables per-agent provider configuration. Each agent row in the agents table has a provider field. The agent runner reads the provider, calls getApiKey(provider), and uses the correct key. Switching an agent from Groq to DeepSeek is a data change in the admin panel, not a code change.

This is the architectural decision that makes multi-model routing practical at the admin level rather than the code level.

---

Resources

• —Supabase Vault (pgcrypto) — how to encrypt sensitive fields at rest using the built-in pgsodium extension; the right approach for multi-user systems
• —Groq API keys — where to generate and rotate Groq keys; rotation invalidates old keys immediately
• —DeepSeek API keys — same rotation pattern as Groq; the vault handles both through the same interface
• —Anthropic API keys — key rotation steps; critical to rotate before a key is compromised, not after

Related Posts

• —I Built My Own AI Content Team: Content Manager, CMO, and CTO Agents — the agent system that consumes keys from this vault
• —Groq vs. DeepSeek vs. Llama-3.3-70B: Why I Mix Models Instead of Picking One — why having multiple providers in the vault enables per-task model routing
• —Case Study: santoshpaudel.me — A Portfolio That Runs Like a Business — the full platform that the vault lives inside

---

Building a platform with multiple AI providers? I design agent systems with centralized key management as a default. See my services or get in touch.