What Is BYOK (Bring Your Own Key) and Why Does It Matter?

BYOK — bring your own key — is one of the most overloaded terms in enterprise software. In cloud storage it describes customer-managed encryption keys that prevent a provider from decrypting your data without your authorisation. In AI tools it almost always means something different: you supply your own API key to a model provider so inference runs under your account and your billing. Both are real, both matter, and conflating them leads to real miscalculations about what a given product actually protects.

This article defines each meaning precisely, explains what changes when you enable BYOK in an AI email tool, and names the things BYOK does not change.

Two things BYOK means — and why the difference matters#

The original BYOK is a cloud-encryption concept. When you store data in Amazon S3, Google Cloud Storage or Azure Blob, the provider encrypts it at rest using their own keys. With customer-managed keys — sometimes marketed as BYOK, sometimes as CMEK — you generate or import the master key into the provider's key management service. The provider still performs the encryption operation, but your key authorises it. Revoke the key and the provider cannot decrypt your data.

In AI tooling, BYOK refers to something different: you bring your own API key to a model provider such as OpenAI or Anthropic. Instead of the app vendor using their own shared account to call the model on your behalf, your requests route through your account. Billing accrues to you. Your usage is governed by your agreement with the model provider, not the app vendor's terms.

The confusion is understandable — both involve a key you hold. But one controls decryption of data at rest in cloud infrastructure; the other controls billing and data-handling terms on live inference requests. They operate at different layers and guarantee different things.

How BYOK works in an AI email tool#

When you enable BYOK in an AI email client, the call to the model changes hands. A properly built implementation follows these steps.

1. 1

   Generate an API key

   Create an API key at your model provider — for example, at platform.openai.com — and paste it into the app's settings. The key ties subsequent inference requests to your account.

2. 2

   Encrypted storage

   The app stores the key encrypted at rest. A secure implementation uses envelope encryption: your key is wrapped with a separate key before being written to the database. The plaintext never appears in logs or error messages.

3. 3

   Runtime decryption in an isolated worker

   When the app needs to call the model, it decrypts your key in a server-side worker at call time. The plaintext key is used for that single request, then discarded. It does not travel to the browser or appear in application logs.

4. 4

   Inference under your account

   The model provider receives the request under your credentials. Data handling, retention policy, and any zero-retention options are governed by your agreement with that provider, not the app vendor's.

5. 5

   Billing to your account

   Your provider's dashboard shows usage and charges it directly to your account. You can inspect, cap, or revoke the key from there at any time without involving the app vendor.

BYOK for AI vs BYOK for encryption: what each changes#

The table below maps both types across the dimensions that matter most when evaluating an AI email product.

What BYOK does not guarantee#

BYOK for AI is sometimes described as a privacy control, and it does shift real things — but it does not do everything buyers assume.

What it changes: inference requests are processed under your account, so data-handling terms apply between you and the model provider. If you choose a provider with strong default policies, those apply to your requests. As of 2026, the OpenAI API does not use submitted data to train its models by default. Zero-data retention — where inputs and outputs are processed in memory only and discarded after the request completes — is available to enterprise customers on eligible endpoints, but requires an enterprise agreement and is not a self-serve toggle on standard pay-as-you-go accounts.

What it does not change: BYOK does not affect how the app stores your emails, logs request metadata, retains data in its own database, or handles data in transit between your mail server and its backend. A product that stores email bodies server-side continues to do so regardless of which account handles the AI inference. The app's own privacy architecture — encryption at rest, retention policy, audit logs — is a separate question from which account calls the model.

Common misconceptions about BYOK#

Three misunderstandings come up consistently in conversations about BYOK in AI products.

"BYOK means the AI never sees my emails." The model provider still receives the text you send for inference. BYOK changes which provider, under which account, and under which agreement — not whether a provider processes the content at all. On-device inference, where the model runs locally and no text leaves your device, is the architecture that removes the provider from the picture. BYOK and on-device inference are different options that solve different problems.

"Revoking my key erases my data." Revoking a BYOK API key blocks future inference calls under your account. It does not delete data the app has already stored in its own systems, and it does not delete anything the model provider may have retained under standard terms. For encryption BYOK (CMEK), revoking the master key does deny the provider access to stored data going forward — a meaningfully stronger and categorically different guarantee.

"BYOK is always more secure than a vendor-managed key." A well-operated vendor-managed key in a hardware security module can be as robustly secured as a customer-managed one. BYOK gives you more control and separability — you can revoke unilaterally and the inference account is clearly yours — but it also means operational responsibility. A key deleted or rotated without a transition plan breaks inference for every user on the account.

How AI Emaily handles BYOK#

AI Emaily supports BYOK API keys routed through OpenRouter, a gateway that connects to multiple model providers. When you supply a key, your inference requests run under your account and your provider's data terms rather than ours — you control which model handles your content, and that provider's policies govern retention and processing. Your key is stored using envelope encryption, decrypted only in an isolated server worker at call time, and never written to application logs or returned to your browser. We build AI Emaily, and this architecture was a deliberate choice: inference control stays with the user, and the app cannot silently re-route requests to a different account.

The BYOK setup and key-handling architecture are documented on our security page. If you prefer not to supply a key, the product also operates on our managed inference allocation, with the same no-logging policy on our side — BYOK is a control option, not a requirement for using the AI features.