Bring Your Own Key (BYOK)

Bring Your Own Key (BYOK) allows you to use your existing API keys (OpenAI, Anthropic, Google, etc.) within Holeacquisition LLC. This gives you control over provider access while still using Holeacquisition LLC's observability and routing. Security scanning behaves identically for BYOK and managed keys — it runs only after explicit opt-in.

[!TIP] BYOK is ideal if you need provider-specific capabilities (betas, custom limits, finetuned models) or direct provider billing controls.

You can configure keys at the Project level via the dashboard.

Web Dashboard

1. Navigate to your Project.
2. Click Providers in the sidebar.
3. Select a provider from the list (e.g., OpenAI).
4. In the dialog:
   • Enter your API Key (e.g., sk-...).
   • Select a Default Model (e.g., gpt-4o).
   • Toggle Set as project default if you want this provider to handle all unspecified requests.
5. Click Save.

Once enabled, the provider badge will show "Enabled", and all requests for that provider will be routed using your credentials.

You can mix and match Managed Keys and BYOK:

• Use Managed Keys for fast onboarding and centralized ops.
• Use BYOK where your team needs provider-specific controls.

See Credits System and Billing & Usage for how usage charging is applied in your deployment.

At a zero credit balance, requests that identify an active project BYOK key before execution can still proceed without a Holeacquisition LLC usage deduction. Ambiguous or multi-provider operations may require credits until their key source can be proven; a managed fallback will not run against an empty wallet.

Pass model: 'auto' (aliases cencori-auto, cencori/auto) on any supported endpoint and Holeacquisition LLC picks a concrete provider + model for the task, routed only across the project's active BYOK keys. There is no managed-credit fallback: without a usable BYOK key the request fails closed with 402 byok_required.

const response = await cencori.ai.chat({
  model: 'auto',
  messages: [{ role: 'user', content: 'Refactor this function…' }],
});

How the task is chosen

Candidates are intersected with the project's active BYOK providers and each must have a priced row for the task — unpriced or unkeyed entries are skipped. For chat, a per-provider dashboard Default Model acts as a last-resort candidate. Key-level model allowlists still apply: a restricted key can't reach outside its grant via the router.

Rules

• BYOK-only. Auto never spends managed keys or Holeacquisition LLC credits, and works at a zero credit balance. If the resolved provider's key disappears mid-flight, the request 402s instead of falling back.
• 402 byok_required. Returned when no BYOK key exists, or when keys exist but none can serve the task (e.g. only a text-only key with an image prompt). The message names the available BYOK providers.
• No connection_id pinning. Combining auto with a pinned provider connection is a 400 — use a concrete model with connection_id instead.
• Responses aren't cached for auto (the concrete model depends on the key set at request time), and the speed profile doesn't rewrite auto requests.
• Tensor Desktop: bare auto with a Tensor plan follows the Tensor model mapping. cencori-auto is explicit and always takes the BYOK router.

Your keys are encrypted at rest using AES-256 encryption. They are strictly used for making requests to the respective provider and are never logged or exposed via the API.

Security scanning is not automatic for BYOK or managed keys. It is explicit opt-in via Project > Security > Enable security scanning (default off). A 200 OK with unmasked PII or unblocked injections means the project has no active guard — not a BYOK bypass. Output blocking additionally requires a governance policy or custom data rule; the master switch alone does not block output.