BYOK -- Bring Your Own API Keys

Teams deploying AI agents in production face a fundamental tension: you need a governance layer between your agents and the LLM providers, but that governance layer needs access to your provider API keys. If the governance platform holds your keys, you are trusting a third party with credentials that can generate unbounded costs on your behalf. If you self-host everything to avoid that trust relationship, you lose the managed dashboard, centralized logging, and team collaboration features that make governance practical.

BYOK (Bring Your Own Key) resolves this tension. You add your provider API keys to the Govyn platform, where they are encrypted with AES-256-GCM before touching any storage layer. Keys are decrypted only in-memory, only at the moment a request is forwarded to the provider, and only inside the proxy process. No key material is ever logged, cached in plaintext, or exposed through API responses.

The result is a managed governance platform where you retain full ownership and control of your API credentials.

The API key security problem

Every AI agent deployment faces the same API key dilemma. The agent needs to call an LLM provider — OpenAI, Anthropic, Google Gemini, or others — and that call requires an API key. The question is: who holds the key?

Option 1: The agent holds the key. This is the default approach for most agent frameworks. The API key is set as an environment variable or passed in configuration. The problem is that agents can leak keys through logs, error messages, subprocess environments, or tool calls. More fundamentally, the agent can bypass any SDK-based governance wrapper by making direct HTTP calls with the real key. This is the approach that Govyn's proxy architecture was designed to eliminate.

Option 2: The governance platform holds the key. The agent authenticates with a proxy token and the platform forwards requests using its own API key. This solves the agent bypass problem but introduces a new one: you are trusting the platform operator with credentials that can generate arbitrary costs. If the platform is breached, all customer keys are exposed. If the platform has an outage, you cannot fall back to direct provider access because you have no separate key.

Option 3: BYOK with encryption at rest. You provide your own keys. They are encrypted before storage. They are decrypted only when needed for a specific request. The platform never stores keys in plaintext, never logs them, and never exposes them through any interface. You maintain your own billing relationship with each provider. You can rotate keys at any time. This is the approach Govyn uses.

How BYOK works in Govyn

The BYOK workflow in Govyn is straightforward. You add your provider API key through the dashboard or API. The key is encrypted immediately — before it reaches the database — and stored as an encrypted blob. When an agent sends a request through the proxy, the proxy decrypts the key in memory, uses it to forward the request to the provider, and discards the decrypted value after the request completes.

At no point does the plaintext key exist on disk, in logs, in error reports, or in API responses. The only persistent representation of the key is the encrypted column in the database and a keyPreview field containing the first four and last four characters (e.g., sk-pr...xK2m), which is stored at write time so that the dashboard can display a recognizable identifier without ever decrypting the full key.

The key flow, step by step:

1. You submit the key — via the Settings page in the dashboard or the POST /api/v1/api-targets endpoint.
2. Immediate encryption — the API service encrypts the key using AES-256-GCM with a unique initialization vector (IV). The encrypted ciphertext, IV, and authentication tag are concatenated and stored as a single blob in the database.
3. Key preview extracted — the first and last four characters of the plaintext key are stored in a separate keyPreview column for dashboard display. The plaintext key is then discarded from server memory.
4. Request-time decryption — when an agent request arrives, the proxy loads the encrypted key for the target provider, decrypts it in memory, attaches it to the outbound request as the appropriate authorization header, and forwards the request.
5. Key discarded — after the provider response completes, the decrypted key value is garbage-collected. It exists in memory only for the duration of the HTTP request.

Encryption architecture

Govyn uses AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode) for all API key encryption. This is the same encryption standard used by financial institutions, healthcare systems, and government agencies for protecting sensitive data at rest.

AES-256-GCM is an authenticated encryption algorithm, which means it provides both confidentiality (the data cannot be read without the key) and integrity (the data cannot be tampered with without detection). The GCM mode produces an authentication tag alongside the ciphertext; if any byte of the ciphertext or the tag is modified, decryption fails. This prevents both data theft and data manipulation.

The encryption flow works as follows:

1. Key derivation — the master encryption key is a 32-byte (256-bit) value derived from the ENCRYPTION_KEY environment variable, which is a 64-character hexadecimal string. This key is loaded into memory when the process starts and is never written to disk or logs.
2. IV generation — for each encryption operation, a unique 12-byte initialization vector (IV) is generated using a cryptographically secure random number generator. Reusing an IV with the same key would compromise security; generating a fresh IV for every key storage operation prevents this.
3. Encryption — the plaintext API key is encrypted using AES-256-GCM with the master key and the unique IV. The output is the ciphertext (same length as the plaintext) and a 16-byte authentication tag.
4. Storage — the IV, authentication tag, and ciphertext are concatenated into a single buffer and stored as the encrypted value in the database. The IV is prepended because it is needed for decryption but is not secret.
5. Decryption — to decrypt, the proxy reads the stored buffer, extracts the IV (first 12 bytes) and authentication tag (next 16 bytes), and decrypts the remaining ciphertext using the master key. If the authentication tag does not match, decryption fails and the request is rejected.

Per-organization isolation is enforced at the application layer. Each organization's API target records are scoped by orgId, and all database queries include the organization filter. An organization cannot read, modify, or decrypt another organization's API keys.

Supported providers

BYOK works with every provider that Govyn supports. Each provider gets its own API target entry in the dashboard, with its own encrypted key and endpoint configuration.

• OpenAI — GPT-4o, GPT-4o-mini, o1, o3, and all models via the OpenAI API. Key format: sk-proj-... or sk-...
• Anthropic — Claude Opus, Sonnet, Haiku (all versions) via the Anthropic API. Key format: sk-ant-...
• Azure OpenAI — all deployed models via your Azure OpenAI resource endpoint. Uses Azure API keys or Azure AD tokens.
• Google Gemini — Gemini Pro, Flash, and Ultra via the Gemini API. Key format: AIza...
• Mistral — Mistral Large, Medium, and Small via the Mistral API.
• Cohere — Command R, Command R+ via the Cohere API.
• Ollama — locally-hosted models. No API key required, but the endpoint URL is configured as an API target for routing.
• Custom endpoints — any OpenAI-compatible API endpoint (vLLM, llama.cpp, LocalAI, LM Studio, and others). Configure the base URL and authentication header.

When the proxy receives a request, it determines the target provider from the model identifier in the request (e.g., gpt-4o routes to OpenAI, claude-sonnet-4-20250514 routes to Anthropic). The proxy then looks up the appropriate API target for that provider within the requesting organization, decrypts the stored key, and forwards the request. See the full list of supported providers on the integrations page.

Setting up BYOK

Adding your provider API keys to Govyn takes under two minutes. Here is the step-by-step process:

1. Navigate to Settings — in the Govyn dashboard, open the Settings page and find the API Targets section.
2. Click Add Provider — the Add Provider form opens with a dropdown of supported provider types.
3. Select provider type — choose OpenAI, Anthropic, Azure OpenAI, Gemini, Mistral, Cohere, Ollama, or Custom. This determines the default base URL and authentication header format.
4. Enter your API key — paste the API key from your provider's dashboard. The key is shown briefly during entry, then masked. For custom endpoints, also enter the base URL.
5. Save — the key is encrypted with AES-256-GCM and stored. The dashboard displays only the keyPreview (first and last four characters) from this point forward.
6. Start routing requests — agents can immediately route requests through the proxy to this provider. No additional configuration is needed if the provider type matches the model identifiers in your agents' requests.

You can also manage API targets programmatically through the POST /api/v1/api-targets, GET /api/v1/api-targets, PATCH /api/v1/api-targets/:id, and DELETE /api/v1/api-targets/:id endpoints. All endpoints require organization-scoped authentication via Clerk.

Key rotation

Rotating API keys is a standard security practice — when a key may have been exposed, when team members leave, or on a regular cadence as part of your security policy. Govyn supports zero-downtime key rotation.

The rotation process:

1. Generate a new key — in your provider's dashboard (OpenAI, Anthropic, etc.), create a new API key. Do not delete the old key yet.
2. Add the new key to Govyn — create a new API target entry with the new key, or update the existing entry. If you create a new entry, both the old and new entries coexist temporarily.
3. Verify — route a test request through the proxy to confirm the new key works correctly. Check the activity log in the dashboard to confirm successful forwarding.
4. Remove the old key — delete the old API target entry from Govyn, then revoke the old key in the provider's dashboard.

Because both keys are valid simultaneously during the rotation window, there is no period where requests fail. The old key continues to serve requests until you explicitly remove it. This is particularly important for production environments where even brief downtime is unacceptable.

For teams with strict rotation policies, we recommend rotating keys quarterly at minimum. Set a calendar reminder or integrate key rotation into your existing secrets management workflow.

Multi-key management

Many teams need more than one API key per provider. Common scenarios include:

Separate keys per team or project

Different teams within an organization may have separate provider accounts or billing projects. The marketing team's GPT-4o usage should be billed to the marketing budget, while the engineering team's usage goes to the engineering budget. Each team adds their own OpenAI key as a separate API target, and routing policies direct each team's agents to the appropriate key.

Rate limit distribution

Provider rate limits are per-key. A single OpenAI key might be limited to 10,000 requests per minute. By distributing requests across multiple keys, you can achieve higher aggregate throughput. Govyn can be configured to load-balance requests across multiple API targets for the same provider.

Failover keys

If a primary key is revoked, rate-limited, or experiencing provider-side issues, a backup key ensures continuity. Configure a secondary API target as a fallback that activates when the primary returns errors.

Testing and staging

Use separate API keys for staging and production environments. Staging keys may have lower rate limits or be attached to a separate billing account with spending alerts. This prevents accidental production spend during testing.

All API targets within an organization are visible in the Settings page, listed with their provider type, keyPreview, and creation date. Keys from different providers are grouped visually for easy management.

BYOK vs platform-managed keys

Some AI governance platforms offer their own API keys — you pay the platform, and they pay the LLM provider. This model simplifies initial setup but creates significant security, cost, and compliance implications. Here is how the two approaches compare:

BYOK means no markup on provider pricing. You pay OpenAI, Anthropic, and other providers directly at their published rates. Govyn charges for the governance platform, not for API access.

Security guarantees

Govyn's BYOK implementation provides the following security guarantees:

• AES-256-GCM encryption at rest — all API keys are encrypted before storage using authenticated encryption. Ciphertext without the master key is computationally indistinguishable from random data.
• Unique IV per encryption — every key encryption operation uses a fresh, cryptographically random initialization vector. IV reuse, which would compromise GCM security, is prevented by design.
• Authentication tag verification — GCM's authentication tag detects both accidental corruption and intentional tampering. Modified ciphertext fails decryption.
• Keys never logged — plaintext API keys are excluded from all application logs, error handlers, and diagnostic output. The error handler strips sensitive details in production.
• Keys never in API responses — the GET /api/v1/api-targets endpoint returns keyPreview only, never the encrypted or decrypted key value.
• Preview stored at write time — the keyPreview column is populated when the key is first stored. Listing API targets never triggers decryption.
• TOCTOU-safe updates — API target update operations use updateMany with the organization ID filter, preventing time-of-check to time-of-use race conditions where one organization could modify another's targets.
• Per-org isolation — all database queries for API targets are scoped by orgId. Cross-organization access is prevented at the query level.
• In-memory decryption only — decrypted key material exists only in process memory during the request lifecycle. It is not written to disk, not cached in plaintext, and is eligible for garbage collection immediately after use.

Compliance benefits

For teams operating under regulatory requirements, BYOK provides concrete compliance advantages over platform-managed key models.

HIPAA

The Health Insurance Portability and Accountability Act requires covered entities to maintain control over access credentials for systems that process protected health information (PHI). With BYOK, your API keys remain under your organization's control. You determine when keys are created, rotated, and revoked. The encryption at rest satisfies HIPAA's technical safeguard requirements for data protection. Audit logs provide the access records needed for HIPAA compliance reporting.

SOC 2

SOC 2 Type II audits evaluate the security, availability, and confidentiality of customer data. BYOK with AES-256-GCM encryption satisfies the encryption control requirements. The keyPreview pattern (storing only a partial identifier, not the full key) satisfies the data minimization principle. Zero-downtime key rotation satisfies the access control and credential management requirements. Complete audit logging of all API target operations satisfies the monitoring requirements.

GDPR

The General Data Protection Regulation requires data minimization and purpose limitation. BYOK means Govyn stores only what is necessary — an encrypted blob and a preview — not the plaintext key. Data subject access requests (DSARs) for API key data can be fulfilled by providing the keyPreview and encryption metadata. The right to deletion is straightforward: deleting an API target entry removes the encrypted key from the database permanently.

For enterprise teams requiring formal compliance documentation, contact us for detailed security architecture documentation and our SOC 2 report.

Frequently asked questions

Set up BYOK on Starter plan or above See pricing