Bring Your Own API Key: What That Actually Means for Your Data
The 60-second version
DataLens lets you connect your own model provider key instead of routing through ours. Here is what that changes about where your data goes.
- What "bring your own key" means mechanically
- What does and doesn't change about data flow
- Why this matters for regulated or cautious teams
When you ask DataLens a question, a language model reads it. Which model, billed to whose account, under whose contract — that is what "bring your own API key" decides. DataLens lets you connect your own provider key instead of routing through ours, and this post is the precise account of what that changes, what it doesn't, and who should care.
What "bring your own key" means mechanically
Without BYOK, your questions are served through DataLens's provider account: we hold the key, we get billed, your usage blends into our aggregate quota. With BYOK, you paste a key from your own provider account into your project's settings, and from that point the model calls for that project are authenticated as you.
Concretely, four properties hold:
The key is stored project-scoped, server-side. It lives in our encrypted server-side store, attached to one project — not in the browser bundle, not in URLs, not in logs, not in exported files. A key saved on your production project is invisible to your staging project, and revoking or rotating it on the provider side takes effect immediately, because we read the stored value per request rather than caching it somewhere you can't reach.
It is used as a per-request credential, nothing more. On each model call for that project, the backend attaches your key as the authorization header to the provider request. The key never travels to your browser, and it never travels anywhere except the provider's API.
Rotation and revocation are yours. Rotate the key in your provider console on your own schedule; paste the new value into project settings; the old one dies everywhere the moment the provider invalidates it. Nobody at DataLens needs to be involved, and offboarding a team member from your provider account cannot strand a copy of the key in our UI — there is no copy to strand.
Usage accrues to your account. Spend, rate limits, quota, and throughput tiers are all yours. If your organisation already negotiated an enterprise tier with higher limits, your DataLens traffic rides on it rather than competing with every other customer for ours.
"Project-scoped" in one sentence: each DataLens project holds at most one provider key, used only for that project's model calls. Separate keys for production and sandbox, per-team billing splits, and blast-radius containment on rotation all fall out of that single property.
What changes — and what doesn't — about data flow
This is the section worth reading twice, because BYOK marketing across the industry routinely implies more than the mechanism delivers. Here is the honest ledger.
Where Your Data Goes on One Question (With BYOK)
Process FlowYour question plus schema context leaves for the provider
The turn's messages — your question, the relevant table and column definitions, and the conversation so far — are sent to the model provider, authenticated with YOUR key. This is how text-to-SQL works: the model must see the question to answer it.
The provider returns SQL, billed to your account
Usage, spend, and rate-limit consumption appear in your provider console under your contract, not ours. Your data-processing agreement with the provider governs this leg.
DataLens executes the SQL against your warehouse itself
Query execution never touches the model provider. It runs under DataLens's read-only warehouse credentials against your curated views — the same least-privilege path as without BYOK.
Results return for summarisation
A capped sample of result rows goes back to the provider for the prose summary, then the answer renders with its SQL attached. Revoke the key and steps 1, 2 and 4 stop; step 3's warehouse access is governed separately.
What changes: who is billed, whose quota is consumed, whose usage dashboard shows the traffic, whose contract governs the provider leg, and who can cut access unilaterally. For procurement and security reviews, the important shift is that the provider relationship becomes direct: your organisation's agreement with the model provider — including its data-processing and retention terms — covers these calls, rather than DataLens's.
What doesn't change: the provider still sees the turn's messages. This is the point most worth underlining. text-to-SQL requires the model to read your question, the relevant slice of your schema, and enough conversation history to resolve follow-ups. Authenticating with your key changes who pays and whose contract applies — it does not and cannot hide the question text from the model answering it. Any vendor implying otherwise is selling you a misunderstanding.
Warehouse access doesn't change either. The key authorises model calls; it grants the provider nothing — no access to your warehouse, no credentials, no network path. Execution still runs through DataLens's own read-only role against the curated analyst surface you exposed, which is why the least privilege setup for your tables matters exactly as much with BYOK as without it.
The sentence to carry into your security review: BYOK moves billing, quota, and contractual coverage to your provider account. It does not keep prompt contents from the provider — the model must see the turn to reason over it. If your requirement is that schema and questions never leave your network, the answer is not BYOK; it is the local endpoint option below.
The local endpoint option. For teams where even the provider leg is unacceptable, DataLens supports pointing a project at a compatible endpoint you control — a VPC-hosted gateway or a self-hosted model behind your own boundary — instead of the public provider API. The key mechanism is the same (your credential, your project scope), but the turns stay inside infrastructure you govern. It costs you the provider's frontier capability and operational burden in exchange for containment; most teams don't need it, and the ones that do know who they are.
Why this matters for regulated or cautious teams
If you are a five-person startup on our default key, BYOK buys you little and we will say so. It matters in three situations:
Procurement requires a direct provider relationship. Regulated buyers — finance, health, government-adjacent — typically need to show that every sub-processor handling their data is covered by their agreements, not a vendor's. BYOK converts the model provider from "DataLens's sub-processor" into "our existing provider, under our existing DPA," which is often the difference between a six-week review and a checkbox.
Key lifecycle policy already exists. Organisations with rotation schedules, per-environment key separation, and instant-revocation expectations get all of it for free, because the credential is theirs. Your incident response runbook ("revoke the key, traffic stops") works without modification and without calling us.
Spend attribution and guardrails live in your cloud bill. Teams that budget AI spend per cost centre, enforce per-key rate limits, or alert on usage anomalies keep doing all of that in the console they already monitor. DataLens traffic becomes one more line in a governed account rather than an opaque sub-charge.
None of this makes the default key unsafe — it runs the same request path, minus your contract and your dashboard. BYOK is about control surface, not about a different level of care. Choose it when your organisation's machinery (reviews, policies, billing) works better holding the credential directly, and skip it when that machinery would just add ceremony.
Frequently asked questions
Does BYOK mean DataLens never sees my data?
No. DataLens still orchestrates the request: it assembles the schema context, sends the turn, receives the SQL, runs it against your warehouse, and renders the answer. BYOK changes whose provider credential authenticates the model leg. DataLens's role in the pipeline is unchanged, and our access remains what it always was — orchestration over data you connected, not storage of it.
Does the provider store my messages?
That is governed by your agreement with the provider and your account's retention settings — which is precisely the point of BYOK. With our key, our terms apply; with yours, yours do, including zero-retention or enterprise privacy terms you negotiated. Check the provider's documentation for your tier rather than assuming either way.
What happens if I revoke or rotate the key mid-project?
Model calls for that project fail immediately with an authentication error — no grace period, no cached credential continuing quietly. Warehouse data, saved questions, and history stay intact; only new model calls stop until a valid key is saved. That immediacy is the intended incident-response property.
Can I use different keys for different projects?
Yes, and you should. Production, staging, and per-team projects each hold their own key, so rotation blast radius is one project, spend attribution is per key, and revoking a contractor's sandbox access touches nothing else.
Does BYOK change what the AI can access in my warehouse?
Not at all. Warehouse access is a separate credential (DataLens's read-only role, scoped to your analyst views) and is unaffected by which provider key authenticates model calls. Narrowing the AI's world — views, redaction, row limits — is configured the same way with or without BYOK.
When should I pick the local endpoint instead?
When the requirement is containment rather than contracting: schema, questions, and results must not traverse the public provider API at all. Expect a capability and operations tradeoff — you gain network control and lose the frontier model's edge plus the provider's reliability burden. If your review only demands your DPA and your audit trail, BYOK suffices.
The summary
- BYOK means your provider key, stored project-scoped and server-side, authenticating that project's model calls as you.
- It changes billing, quota, usage visibility, contractual coverage, and revocation — all moving to your provider account.
- It does not change the fundamental data flow: the provider still sees the turn's messages, because the model must read the question to answer it.
- Warehouse access is a separate credential and path, governed by your least-privilege setup either way.
- Teams needing containment rather than contracting should evaluate the local endpoint option, where turns stay inside infrastructure they govern.
Chinmay Raibagkar
About author →Founder of DataLens AI. He helps non-technical teams read their ad and database numbers with confidence — which number to trust, what to do next, and what to ignore.