Does Bringing Your Own API Key Make an AI App Private? Local AI, Cloud Logs and the Real BYOK Boundary

“You supply the API key, so your documents never pass through the app company” is only true for a very specific architecture. Owning the credential does not prove that requests travel directly from device to model vendor. Sending requests directly does not prove that the model vendor retains nothing. And turning off one project logging switch does not erase separate caches, files, background tasks, search tools, backups, or the app’s own database. The real privacy contract must account for which content leaves the device, which service receives it, what purpose each service serves, how long it retains information, and what users can actually delete.

Consider a local-first memory application that retrieves three passages from a PDF and submits those passages, with a question, to an external model under the user’s key. The original PDF may never have been uploaded. But the extracted text, document titles, question and system context still crossed a trust boundary. “No document upload” and “no private information transmitted” are therefore different claims.

Three BYOK architectures that should not share one privacy label

Figure 1. Four deployment patterns have different credential owners, data routes, and retention obligations; BYOK does not imply local-only processing.

In a device-to-provider architecture, the application locally selects evidence and sends it over HTTPS to the model provider. Its developer’s backend need not see the prompt, but the provider may handle it under a separate data policy. The key remains exposed to the security of the endpoint device, local instrumentation, a compromised app build, and any intermediary traffic inspection.

In an app-operated proxy architecture, the request or credential traverses the app company’s servers before reaching the vendor. Reverse proxies, tracing tools, crash reports, observability systems and backups may create additional copies. Even when the user pays the provider directly, the application company may act as a data processor and must document that role.

In a user- or organization-operated gateway, the user controls an inference gateway and may configure access, auditing and retention, but security still depends on actual server settings, outgoing dependencies, identity enforcement and upgrades. A self-hosted gateway that silently routes to another cloud provider is not equivalent to fully local inference.

Local inference is a fourth, distinct mode. Model execution and source retrieval can remain on the device, but telemetry, cloud sync, web search and remote embedding may still transmit data. Responsible product copy should distinguish Local AI, Cloud AI, Web Search, Synchronization and Diagnostics as separate controls. Before submitting retrieved passages to the cloud, the UI should ideally preview the selected content scope, not only the model name.

Gemini’s October 26, 2026 change: default storage depends on project age

Figure 2. Provider-side logging and application processing are separate trust boundaries; this is not a Gemini project-settings screenshot.

Google’s Gemini API Logs and Datasets documentation says that for new projects created on or after October 26, 2026, Generate Content API requests are stored by default, equivalent to store=true; older projects retain their earlier default of store=false unless logging was enabled. The Interactions API has separate default storage behavior because it also supports server-managed state. Project owners can control settings in AI Studio, and supported operations offer request-level settings.

This does not mean every existing Gemini user was switched to forced logging that day. Project creation date, paid-tier logging availability, endpoint and explicit overrides matter. The published documentation says supported project logs normally have a default expiration window of up to 55 days, configurable to 7, 14, 28 or 55 days. Entries saved to datasets have a distinct lifetime and do not expire with ordinary project logs. Vendor abuse-monitoring logs and developer-owned project logs are separate; data deliberately shared by a developer for feedback and model improvement is another processing purpose. Logging enabled is not automatically identical to model training, and logging disabled does not automatically eliminate every service-side record.

For a BYOK product, this is an important design signal: do not infer the current storage policy from a vendor name or a static slogan. Use project-appropriate settings, set an explicit minimal-storage preference where the endpoint supports it, and verify the effective behavior with a safe test project. A request-level store=false control is not an end-to-end zero-retention guarantee.

OpenAI’s Zero Data Retention is an eligibility-based endpoint policy

OpenAI’s Platform Data Controls documentation distinguishes abuse monitoring from application state. According to the current API policy, content submitted through the API is not used to train OpenAI models unless an eligible customer explicitly opts into that use. The ordinary retention policy still matters. Eligible, approved organizations can enable Zero Data Retention (ZDR), which treats the store setting as false for supported Responses and Chat Completions calls even if a request sets it to true.

ZDR is not a universal switch that every BYOK user receives automatically. It does not govern the app’s own storage, remote MCP servers, third-party connectors, separate endpoint state, files, vector stores, hosted containers, caches or backups under unrelated policies. A remote MCP server is an independent data destination with its own retention rules. Background execution and hosted execution environments may create short-lived application state for their own tasks, and some features are not eligible for the same ZDR protections.

A multi-provider application should maintain an explicit data-policy contract for each provider and endpoint: whether it may receive document passages, whether response storage is allowed, what the effective project settings are, whether third-party tools can execute, where it processes requests, what can be deleted, and whether failures may be retried. An unsupported or unverified policy capability should be displayed as unknown, not silently assumed to satisfy the strongest requirement. A shared schema does not make vendor policies interchangeable.

Five likely failure paths in local-RAG-plus-cloud products

Figure 3. Selective cloud egress is an architecture goal and not a certified RecalAI product behavior.

First: context assembly. A hybrid retriever may select evidence using full-text search, embeddings, reranking and a token budget. Even if the user asks a short question, the outgoing model request may contain detailed source passages. Apply namespace, authorization, user-selected knowledge scope and evidence budget at the point where the outgoing prompt is assembled. A large model context window is not permission to send an entire private document.

Second: credential storage and operational logs. Use operating-system credential facilities such as properly configured Keychain, Keystore and desktop secret stores. Never bundle long-lived user tokens in distribution assets, include authorization headers in analytics events, or emit full private prompts to generic crash monitoring. If the app runs a proxy, be explicit about whether the server receives the key and how that access is restricted, logged or revoked.

Third: implicit tool calls. Web Search, remote MCP, file tools and browser/computer-use flows can introduce additional processors. “Use a cloud model” should not silently authorize “send local contract excerpts to an unrelated third-party tool.” External tools require their own network, data-classification and authorization checks, with safeguards against untrusted web content directing privileged actions.

Fourth: deletion. Deleting a local document or vector record only establishes a local application event. Previous summaries may still exist in a provider project log, a hosted conversation, an observability trace, a tool cache, a proxy error dump, or a backup. Users need separate statements for immediate local retrieval invalidation, service-side deletion operations and eventual retention expiry. The UI should not say “permanently forgotten everywhere” unless evidence supports that scope.

Fifth: device sync. A local-first application may sync encrypted or plaintext data through a service. End-to-end encrypted sync and server-readable sync are different security models. The product must account for recovery keys, device revocation, backups, deletion windows, and what happens when a user disables cloud inference on one device but another still has an active session.

An auditable privacy acceptance test

Figure 4. A synthetic test can verify local egress and key revocation, but cannot prove erasure of provider logs and backups.

Use only synthetic documents and an isolated test account. First verify that “Local AI + Web Search off + Sync off” sends no knowledge content to external model or tool providers. Next enable a cloud provider and inspect a controlled gateway capture to confirm the destination and selected evidence scope, while redacting request bodies and secrets from permanent logs. Then verify that application tracing, crash and analytics pipelines never persist credentials or unapproved source text. Finally revoke a key and delete a test source: subsequent prompt assembly must stop using the revoked credentials or memory chunks. Separately inspect the provider’s effective project logging settings, noting what can only be verified from an authorized organization account.

The test record should capture: source namespace, selected evidence IDs, provider and endpoint, outbound policy, optional storage preference, permitted tools, verified account controls, user consent, key-revocation state and the resulting network destinations. Fail closed for missing permissions. Do not silently claim a product-level security certification because a small network test passed.

These tests are especially useful for personal memory products: a user can see the local evidence used by an answer, understand when it crosses into a provider’s infrastructure and distinguish a server-side storage choice from an application-side data deletion promise. That is a durable user decision problem, not a one-week reaction to an API changelog.

A BYOK data-flow acceptance matrix, without unverifiable promises

An application should evaluate four execution modes against the same privacy questions. Direct device-to-provider: the user’s credential is held in an operating-system secret store, and approved retrieved content goes to the model vendor without intentionally traversing the app developer’s backend; telemetry and sync remain separate risks. App-operated proxy: the developer’s server is in the request path and may technically access credentials, prompts, traces and error snapshots; retention and observability controls become material product claims. User-operated gateway: the destination is user-selected, but it may chain to another cloud provider, and the user still needs audit and admin-access controls. On-device inference: model context can remain local, yet separate web search, remote embeddings, crash diagnostics and sync may still transmit data.

For each mode, record six properties: where credentials live, the actual outbound destination, who can read source passages, which logs or caches are retained, whether third-party tools may run, and the scope of deletion that can be verified. A “three chunks only” setting is not sufficient if one chunk contains a private contract clause or another user’s material. Scope the requested content by principal and knowledge namespace, apply permissions before prompt assembly, and make provider choice and outgoing content understandable to the user.

A synthetic acceptance test can place an otherwise unused marker in a fake document, disable search and sync in local mode, and inspect controlled outbound traffic for the marker. In explicitly approved cloud mode, compare the sent passage IDs with the intended selection, then revoke the key and remove the source to ensure subsequent outbound prompts stop using both. These checks are test designs, not completed XBSTACK RecalAI device runs. They cannot certify what happens to all provider-side abuse logs, backups or legally required retention. Their purpose is to turn vague BYOK privacy marketing into a falsifiable, endpoint-specific engineering contract.

What should this add beyond existing BYOK clients? Some existing apps, such as Byokey, explicitly market direct device-to-provider calls and on-device Keychain storage without routing prompts through the app company’s proxy. That is the vendor’s published architecture claim, not an XBSTACK network audit. Other credential tools offer optional cloud vaults or relays, so the trust boundary changes even when both advertise bring-your-own-key. Repeating “your key stays local” is insufficient differentiation. This guide instead asks what retrieved document chunks actually leave the device, whether a proxy could observe them, which provider-side logs remain, and who can revoke or delete which copies. Those questions need a falsifiable endpoint-by-endpoint acceptance method to remain meaningfully distinct from an OpenAI-specific ZDR explainer or a generic local-RAG implementation guide.

Local AI, BYOK and ZDR solve different problems

Local AI reduces the need to transmit source context for inference, but does not automatically disable syncing, telemetry or web retrieval. BYOK lets the user control credentials, model selection and often billing, but does not automatically grant ZDR or prove that the app does not proxy requests. ZDR or controlled retention is a vendor/account/endpoint policy with qualification and limitations. A trustworthy product implements these choices separately and explains them separately. “Not used to train the model,” “not stored as application state” and “never leaves the device” are materially different claims.

This is a sourced architecture study, not a completed RecalAI application privacy certification. XBSTACK did not inspect a production device’s outbound network traffic, live BYOK keys, provider log deletion controls, or end-user retention settings for this draft. The next independent evidence milestone is an opt-in, synthetic traffic test showing the exact data sent under each supported mode and the residual unknowns that cannot be proved by the client alone.

FAQ

If I bring my own key, can the application provider see my prompt? It depends on the architecture. A direct-to-vendor client may bypass the app backend, while an app-operated proxy can receive full requests. Verify the actual network route.

Did Google’s October 26 change force logging on all Gemini customers? No. The new default applies to Generate Content on newly created projects, with existing projects retaining their previous setting; effective project, account and request configurations matter.

Does store=false mean OpenAI ZDR? No. A request storage setting is not proof of organization-level ZDR approval or zero retention by every endpoint, tool or external processor.

Can cloud AI receive only three selected passages from my local documents? Yes, if the application enforces scope, permissions and prompt assembly limits and verifies what is sent. A UI promise alone is insufficient.

Does deleting a local file delete provider logs? Not automatically. Local indexes, hosted sessions, API logs, datasets, caches and backups have separate deletion and retention boundaries.

Official sources and XBSTACK related work

• Gemini API Logs and Datasets
• Google Data Logging and Sharing
• OpenAI Data Controls
• OpenAI Responses migration / state guide
• XBSTACK OpenAI ZDR and MCP Data Boundaries
• XBSTACK RecalAI Hybrid Retrieval
• XBSTACK Agent Memory Implementation