BYOK (Bring Your Own Key)
BYOK (Bring Your Own Key) means you provide your own AI provider API key to a SaaS tool, so all LLM calls run on your account and your bill — not the vendor's. The vendor never sees or proxies your token.
What BYOK actually means in practice
BYOK is shorthand for a deployment pattern where the SaaS application acts as orchestration and UI, but every call to an AI provider (OpenAI, Anthropic, Google Gemini) runs on a credential the customer owns. The vendor never holds the plaintext key; the customer owns the relationship with the AI provider directly.
Functionally, you paste your API key into the SaaS once. The vendor encrypts it at rest, decrypts it inside the worker process at runtime, makes the LLM call with that key, then drops the plaintext. Your provider sees your usual usage pattern (just with the vendor's prompts attached). Your bill comes from OpenAI / Anthropic / Google — not from the SaaS.
It's the opposite of the typical SaaS-AI model where the vendor holds a master account, marks up token spend, and bills you a flat or usage-based fee. BYOK removes the markup and the trust gap in one move.
Why BYOK matters for code-review and dev-tool SaaS
AI code review burns tokens. A single 300-line PR review on GPT-4o runs about $0.05-$0.15. Multiply by 50 PRs/week and 10 engineers and you're looking at $200-$600/month — easily more than the SaaS subscription itself. If the vendor adds a 30-50% markup on top of provider cost (typical), you're paying $260-$900/month for what should be ~$200-$600.
Beyond cost: BYOK lets you audit your own token spend at the provider dashboard, set usage limits and alerts on your account, switch models without asking the vendor to add support, and walk away from the vendor without losing access to your AI workflow (the key is yours).
For regulated or privacy-sensitive teams, BYOK also matters because it cuts the data-flow path. The vendor's prompts reach the LLM via your key — your provider's data-handling agreement applies, not the vendor's separate agreement with the LLM company.
BYOK vs vendor-managed AI
Vendor-managed (the default): the SaaS holds an API key for the LLM provider, bills you a flat or per-seat fee, and absorbs the token cost. Simple, hidden cost structure, but vendor sees every prompt and response.
BYOK: customer holds the API key, pays the LLM provider directly, controls usage limits and model selection. Vendor sees orchestration metadata (which prompts ran, when) but not the cost or quota.
The middle ground is rare: a few vendors let you choose. BYOK is increasingly common in dev-tool space (LGTM, Cursor, some agent platforms) because devs already have their own AI provider accounts and don't want a second markup.
Security model for BYOK keys
A BYOK implementation that doesn't encrypt at rest is worse than no BYOK — you've created a single high-value target containing every customer's provider key. Industry-standard pattern: AES-256-GCM encryption with a server-side master key stored separately (e.g. in HashiCorp Vault, AWS KMS, or a host secrets manager like Fly secrets).
The master key never lives in the same place as the encrypted blobs. Decryption happens in worker process memory at the moment a job fires — never in a request handler, never logged, never returned to the client UI. After the LLM call returns, the plaintext key is dropped by garbage collection.
Display in the customer UI should redact aggressively: show only a prefix (e.g. sk-...AbCd) so users can identify which key is saved without exposing the full secret to anyone with access to the dashboard.
BYOK on LGTM
LGTM follows the BYOK model strictly. When you add an OpenAI / Anthropic / Gemini key in Settings, we validate it against the provider's /v1/models endpoint, encrypt with AES-256-GCM, and store the encrypted blob in MongoDB. The master key lives in Fly secrets.
At review time, the worker decrypts in memory, makes the LLM call, then drops. Your bill comes from OpenAI / Anthropic / Google directly. LGTM doesn't see your token usage, doesn't proxy your requests, and doesn't mark up provider cost.
Per-repo model overrides are a Pro feature — you can pin GPT-4o on a high-stakes payments repo and Claude Haiku on a marketing blog, all running on your single BYOK key.
Examples
// Validate provider key before saving
const res = await fetch('https://api.openai.com/v1/models', {
headers: { Authorization: `Bearer ${rawKey}` },
});
if (!res.ok) throw new Error('Invalid API key');
// Encrypt with AES-256-GCM
const cipher = crypto.createCipheriv('aes-256-gcm', masterKey, iv);
const encrypted = Buffer.concat([
cipher.update(rawKey, 'utf8'),
cipher.final(),
]);
const authTag = cipher.getAuthTag();
// Store { encrypted, iv, authTag } — never the plaintext
await User.updateOne({ _id }, { 'ai.openaiKey': { encrypted, iv, authTag } });See how LGTM implements BYOK
AES-256 at rest · plaintext only in worker memory · zero markup
Go to the product pageFAQs
Does the vendor see my BYOK key in plaintext?
It depends on the implementation. A correct BYOK setup encrypts the key the moment it arrives and only decrypts inside a worker process at the moment a job fires. The plaintext key never persists to disk and never gets logged or returned by an API. Audit the vendor's implementation before trusting their BYOK claim — ask to see the encryption + decryption code.
What happens if my BYOK key gets revoked at the provider?
Rotate it. Get a new key from your provider dashboard (OpenAI / Anthropic / Google), paste it into the SaaS Settings. In-flight jobs using the old key get a 401 from the provider and fail with a 're-key' message; new jobs use the new key immediately. The old encrypted blob gets replaced atomically.
Is BYOK more or less secure than vendor-managed?
More secure for one reason: the vendor never holds the master credential to your AI account. If the vendor gets breached, your AI provider account is unaffected (you just rotate the BYOK key). With vendor-managed, a vendor breach exposes their LLM provider account — which often has higher quotas, broader model access, and a billing relationship with whoever's behind the vendor.
Can I share one BYOK key across a team?
Most teams do. Create an OpenAI / Anthropic / Google organization project, generate a key under that project with usage alerts + monthly limits, and use that single key for the team's SaaS account. Per-engineer keys are cleaner for accounting attribution but more keys to rotate.
Related across LGTM
Related terms
AI code review
AI code review uses large language models (and increasingly multi-agent pipelines) to review pull requests for bugs, security issues, performance regressions, readability, and style — automatically, on every PR, in 30-90 seconds.
LLM code review pipeline
An LLM code review pipeline is the end-to-end system that ingests a GitHub PR webhook, fetches the diff, gathers repo context, runs one or more LLM agents in parallel, synthesizes their outputs, and posts the result back to GitHub as a review with inline comments.
GitHub App permissions
GitHub App permissions are the granular scopes an installed GitHub App requests on a repository: contents (read source), pull requests (read+write), checks (write Check Runs), metadata (read repo info), etc. Each permission level (none / read / write / admin) controls what the App can do with that resource.