What is bring your own key?
Bring your own key is the option for an organization to provide its own API key for the model provider its Digital FTEs use. With a key configured, the FTEs' model calls run against the organization's own provider account, under the organization's own agreement with the provider, and are billed there. Without one, model usage runs on the platform's account and is covered by the plan's token wallet.
The term is the industry's own. It describes the arrangement plainly: the organization brings the key, and the platform uses it on the organization's behalf.
How does BYOK work on ftes.ai?
On ftes.ai an owner or admin adds the key once in the organization's settings. It is encrypted before storage with a key held separately from the data, it is never returned in a response, written to a log, or shown in the workspace after entry, and the audit trail records that a key was added, by whom, and when, without the key itself. The same protection applies to every integration credential.
From that point model usage for that provider bills to the organization's account. The workspace continues to report usage per role, and the wallet continues to meter the platform's own work. Rotating the key is a replace action; removing it returns usage to the platform's account. Both are logged.
What changes and what does not?
Two things change: who is billed for model usage, and whose data handling terms apply to the model calls, which becomes the organization's own agreement with the provider. That matters for organizations that have negotiated specific terms, data residency, or retention commitments directly.
Everything else is unchanged. Every Digital FTE still starts at Level 0, every proposal still passes the approval gate, every published claim still passes the fact gate, every action is still in the audit trail, and the platform still does not train models on customer data. BYOK changes the plumbing beneath the model call, not the governance above it.
- Changes: billing for model usage; whose provider terms apply
- Unchanged: gates, ladder, trail, isolation, no training on your data
- Unchanged: model tier choice per FTE in Setup
When is it worth doing?
It is worth doing when the organization already has a provider agreement with terms it prefers, when procurement requires model usage to sit on a contract the organization holds directly, or when the organization wants model spend consolidated with its other provider usage. It is not necessary for governance; an organization without its own provider relationship gets the same controls on the platform's account.
Managing it means two habits: rotate on the schedule the security policy requires, and keep an eye on the provider's usage dashboard beside the workspace's usage per role, because with BYOK the provider bills the usage and the workspace reports the work.
What is BYOK often confused with?
It is confused with self-hosting, which it is not; the platform still runs the work, and only the model call's account changes. It is confused with a security upgrade; the gates and isolation are the same with or without it, and the key is protected like any other credential. And it is confused with a discount; whether it is cheaper depends on the organization's own provider terms.
It is sometimes assumed to expose the key to the vendor's staff. It is encrypted with a separately held key and is never shown after entry.
Where do you see it?
In the organization's settings, where the key is added, rotated, or removed by an owner or admin; in the audit trail, which records those actions without the key; and in the provider's own usage dashboard, which bills the model usage once BYOK is on.
Related terms: credential, model tier, token wallet, sub-processor, data processing agreement.
A practical sequence for a new organization is to run the first cycle on the platform's account, read usage per role, and then decide whether BYOK is worth the procurement conversation. The controls are identical either way, so nothing about the pilot changes if the key is added later, and the usage record from the first cycle is what makes the provider conversation concrete.