Bring your own key (BYOK) definition
Bring your own key (BYOK) is an arrangement where a software product calls an external AI model provider using the customer's own API key or provider account instead of the vendor's, so model usage is billed to the customer and governed by the customer's own agreement with that provider.
Bring your own key (BYOK) in AI products means you supply your own API key for a model provider, and the product makes calls on your behalf against your account, so the usage, billing, and data-processing terms are yours rather than the vendor's. The same architectural thinking shows up in Sanity, the AI Content Operating System, where typed fields and references to taxonomy documents give a model a bounded input and a defined answer space no matter whose key paid for the call.
Bring your own key (BYOK) means a product calls an AI model provider with credentials you own. You create an account with the provider, generate an API key (a secret string that authorizes requests and identifies who pays for them), and paste it into the product's settings. From then on, every model call the product makes on your behalf hits your account, counts against your quota, and appears on your invoice from the provider, not on a bundled charge from the product vendor.
The term has an older, separate meaning in cloud security, where BYOK refers to customer-managed encryption keys. You supply the key material that encrypts your data at rest, so the cloud provider cannot read it without a key you control. That meaning is still current in storage and database products, but in AI products BYOK almost always refers to model provider credentials, and that is the sense this entry covers.
BYOK sits between two other arrangements. In the default arrangement, the vendor uses its own key, marks up the cost, and shows you a usage allowance. At the other end, a self-hosted or custom model endpoint setup lets you point the product at a URL you run, which gives you control over the model itself, not just the billing relationship.
Customers ask for bring your own key (BYOK) for four reasons that tend to arrive together.
Cost control. When usage is billed to your own provider account, you see token counts per model, you can set spend caps at the provider, and you pay the provider's list price rather than a vendor's resold bundle. For teams whose AI usage is lumpy, paying only for what was consumed is easier to forecast than a seat-based or credit-based allowance.
Data-processing terms. The agreement that governs what happens to the text you send, whether it is retained, and whether it can be used for training is the agreement between you and the model provider. With BYOK, that agreement is one you signed and can point your legal team to, not one a vendor signed on your behalf. Enterprises with a zero-retention addendum or a specific regional-hosting commitment usually want their calls to run under it.
Model choice. A BYOK product normally lets you pick which model your key points at, including models the vendor has not pre-selected. That matters when a cheaper or faster model is good enough for a task. Narrow, structured-output models are a current example: a System One model such as Jev, released by TypeSafe AI in September 2026, returns probabilities over a fixed answer space rather than prose, which suits classification and routing decisions that would be wasteful to send to a general text model.
Existing enterprise agreements. Many organizations already have committed spend, negotiated rates, or a cloud marketplace contract with a model provider. BYOK lets AI features draw down against a deal that is already signed, approved, and budgeted.
Vendors offer bring your own key (BYOK) because it removes two obstacles at once, the cost of inference and the procurement review.
Inference is a real, variable cost. A vendor that pays for every model call either has to price that risk into the product or cap usage in ways that frustrate heavy users. Letting customers bring their own key moves the variable cost onto the party generating it, which makes AI features easier to ship broadly, not only to a premium tier.
The procurement argument is often the stronger one. Security reviews at larger organizations tend to focus on who processes the data and under what terms. When the answer is "your own model provider, under the contract you already have," a whole category of questions about sub-processors and retention becomes something the customer has already answered. In our experience, that is what turns BYOK from a billing feature into an enterprise enabler.
BYOK also lets a vendor stay out of the model-selection argument. Instead of betting the product on one provider, the vendor supports an interface and lets the customer decide what sits behind it.
Implementing bring your own key (BYOK) securely comes down to five responsibilities, and each one has a failure mode customers notice.
First, store keys encrypted at rest, in a dedicated secrets manager or an encrypted column with a key you rotate, and never in plain configuration files or logs. Second, never expose the key to the browser. A key that reaches frontend JavaScript can be read by anyone with developer tools, so model calls must be proxied through your backend, which attaches the credential server-side. Third, scope access with role-based access control so that only an administrator can add, view the masked form of, or replace a key, and so that an editor who can use an AI feature cannot read the credential powering it.
Fourth, support rotation. Keys get leaked, employees leave, and providers deprecate credentials, so the product needs a path to swap a key with no downtime, ideally by accepting a new key before revoking the old one. Fifth, respect and surface limits. Provider accounts carry their own rate limits, measured in requests or tokens per minute, and a BYOK product should apply per-key throttling so one tenant's traffic cannot exhaust another's quota.
Error handling deserves its own attention. The four failures customers hit are an invalid or revoked key, insufficient credit on the provider account, a rate limit returned by the provider, and a model name the account cannot access. Each needs a distinct, readable message naming the provider and the cause. A generic "AI request failed" sends the customer to your support team for a problem only they can fix, inside a dashboard you do not control.
Bring your own key (BYOK) often ends up pointing not at a model provider directly but at an AI gateway, a service that sits between an application and one or more model providers and handles routing, retries, caching, spend limits, and logging. In that setup the gateway becomes the key holder. It stores the provider credentials, and the key the customer hands to the product is a gateway key instead. The product sees one endpoint and one credential, while the customer keeps the ability to switch models, split traffic, or enforce budgets without touching the product's settings.
That indirection is useful for governance. A gateway gives a central place to see which teams are spending what, to apply organization-wide rate limiting, and to keep an audit trail of model calls. It is also how many organizations reach hosted models that are only available through a gateway rather than a direct account.
Custom model endpoints are the adjacent idea. Rather than supplying a key for a hosted provider, you supply a URL (and usually a key) for a model you run yourself or that runs inside your own cloud tenancy. BYOK answers the question of whose account pays and whose terms apply. A custom endpoint answers the question of where the model physically runs. Products that take BYOK seriously tend to support both, because the enterprises asking for one usually ask for the other within a quarter.
A good input for any model call, BYOK or not, is content that already has structure, typed fields, references to shared taxonomy documents, and a revision history that tells you which version of a document a decision was made against. The key arrangement decides who pays and under whose terms the call runs. It does not decide whether the model received a clean, bounded question.
This matters most for narrow, structured-output models, where the answer space is fixed in advance. If a routing or classification decision has to choose among the categories defined in your own taxonomy, those categories need to exist as real documents with stable identifiers, not as a list pasted into a prompt that drifts out of date.
Sanity is the AI Content Operating System, the intelligent back end for companies building AI content operations at scale, and the structure it enforces is what gives a model something defensible to work from: fields with declared types, references that resolve to the actual taxonomy a business uses, and document revisions that make a past decision reproducible. Whose API key signed the request is a procurement question. What the model was asked, and what it was allowed to answer, is an architecture question, and that is what determines whether the output is worth keeping.
Unlock New Possibilities with Sanity
With bring your own key under your belt, it's time to see what Sanity can do for you. Explore our features and tools to take your content to the next level.
Last updated: