> ## Documentation Index > Fetch the complete documentation index at: https://docs.fireworks.ai/llms.txt > Use this file to discover all available pages before exploring further. # Secure Training > Choose the right training surface for your data-privacy needs, and understand what Fireworks retains and how to delete it Fireworks lets you fine-tune models while keeping your data and sensitive components under your control. Across every training surface, one principle holds: **your training data is never used to train Fireworks-owned or shared models**. This page covers training. Inference follows [Zero Data Retention](/guides/security_compliance/data_handling) by default — prompts and generations are never written to persistent storage — so we focus here on the training lifecycle: where your data lives while you train, what Fireworks retains afterward (checkpoints and traces), and the controls you have to delete it. Use it to: * Understand how each training surface handles your data. * Choose the surface that fits your data-privacy requirements. * Know exactly what is retained, what is not, and how to delete it. ## Choosing a training surface Fireworks offers three ways to train, differing mainly in **where your training data lives**: | Surface | Where your training data lives | What Fireworks retains | Your deletion controls | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------- | --------------------------------------------------------------------------- | | **Managed Training** | Uploaded to Fireworks-managed storage (GCS); only a reference link is kept in our database | Dataset, checkpoints, and traces | Delete the dataset anytime after the job; request checkpoint/trace deletion | | **Managed Training + BYOB** | Stays in your own cloud bucket; Fireworks reads it in-place during training, with no copy persisted | Checkpoints and traces only | Revoke bucket access after the job; request checkpoint/trace deletion | | **Training API** | No dataset upload — you load and tokenize data locally; the trainer receives only transient tokenized batches, never a stored dataset file | Checkpoints and traces only | Request checkpoint/trace deletion | For the strictest data governance, use [BYOB](/guides/security_compliance/secure_training/byob) (keep the dataset in your own bucket) or the [Training API](#training-api) (no dataset is ever uploaded to or stored on Fireworks). ## Data retention by surface When training runs on Fireworks-managed storage, training data is stored in Google Cloud Storage (GCS) with only a reference link retained in our database. Customers control deletion of their own datasets. ### Managed Training Retention behavior depends on the job type: | Job Type | Data Generated | Retention / Deletion | | ---------------------- | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SFT — Managed Training | Uploaded dataset only | Customer-controlled; deletable immediately after the job completes | | DPO — Managed Training | Uploaded dataset only | Customer-controlled; deletable immediately after the job completes | | RFT — Managed Training | Input prompts + rollout datasets (generated outputs) | Input prompts: customer-controlled, deletable after the job completes (same policy as SFT and DPO). Rollout datasets (generated outputs): deletable upon request | | Job chunks / artifacts | Intermediate checkpoints | Retained for 30 days, then deleted; deletable earlier on request. Kept so jobs can be retrieved or restarted | | Traces / logs | Request/response metadata | Retained for 30 days, then deleted; deletable earlier on request | ### Training API The [Training API](/fine-tuning/training-api/introduction) works differently: you write the training loop in your own environment, load and tokenize data locally, and send tokenized `Datum` batches to Fireworks GPUs on each `forward_backward` call. What this means for your data: * **No dataset upload step and no dataset file stored on Fireworks' side.** Fireworks never receives your raw JSONL, and for RL or distillation the trainer never sees raw prompt text. * **The trainer does receive the training content** — as tokenized `Datum` batches on every `forward_backward` call. Those tokens are your data; they are processed transiently for the gradient step and are not retained as a dataset. What Fireworks does retain is minimal and deletable on request: * **Checkpoints** — retained for 30 days (deletable earlier on request) so you can restart jobs without losing work. * **Traces / logs** — retained for 30 days (deletable earlier on request) so you can evaluate job performance and improve your training. This barebones retention is by design: it keeps the product easy to use — retrieve checkpoints to restart jobs, and inspect traces to understand and improve training — while your training data is never uploaded or stored as a dataset on Fireworks.

How Fireworks accesses your cloud

Both BYOB and CMEK work by granting a Fireworks identity least-privilege access to a resource in your account — a storage bucket for BYOB, a KMS key for CMEK. Fireworks authenticates as a Google-issued OIDC identity, and you configure your cloud's IAM to trust it. Three properties follow: * **No long-lived secrets.** Fireworks presents a short-lived, automatically rotated token on each call. There is no API key or client secret for you to store, rotate, or risk leaking. * **Nothing runs in your cloud.** Fireworks does not deploy software into your account — it calls your cloud's API from Fireworks infrastructure, as the identity you authorized. * **Scoped to your account.** The token carries your Fireworks account ID as its audience, and you configure your trust to accept only that audience. A token issued for any other Fireworks account is rejected by your own infrastructure, not just by Fireworks. Where federation applies, you pin trust on these values: | Value | Identifier | | ---------------------------- | ----------------------------- | | OIDC issuer | `https://accounts.google.com` | | Fireworks identity (subject) | Provided at onboarding | | Token audience | `` | BYOB and CMEK authenticate as **different** Fireworks service accounts, so their subject identifiers differ — don't reuse one for the other. Two cases don't use this pattern: **GCS BYOB** grants access to Fireworks service account emails directly, with no token audience to scope, and **Azure BYOB** uses the fixed `api://AzureADTokenExchange` audience. Each setup page states which applies. ## Two independent controls BYOB and CMEK address different needs and can be used separately or together: | | What it controls | Use when | | ------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | **[Bring your own bucket (BYOB)](/guides/security_compliance/secure_training/byob)** | *Where the dataset lives* — it stays in your bucket and is read in place, never copied to Fireworks | You need the dataset itself to never leave your storage | | **[Customer-managed keys (CMEK)](/guides/security_compliance/secure_training/cmek)** | *Who holds the key* for data Fireworks does store — datasets and checkpoints on Fireworks-managed storage | You use managed storage but need to control encryption and revoke access | CMEK covers artifacts on Fireworks-managed storage, so it complements rather than replaces BYOB. For the strictest governance, combine BYOB with [secure RFT](/guides/security_compliance/secure_training/secure_rft), or use the [Training API](/fine-tuning/training-api/introduction), where no dataset is stored at all. ## Inference Inference at Fireworks follows Zero Data Retention by default: prompts and generations exist only in volatile memory for the duration of the request and are never written to persistent storage or used to train any model. For full details, including the Response API storage exception and how to opt out, see the [Zero Data Retention policy](/guides/security_compliance/data_handling). ## Customer controls The following controls are available for training workloads: | Control | How to exercise it | | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Delete a fine-tuning dataset | Delete via the Fireworks console or API after the job completes. | | Request deletion of checkpoints, traces, or RFT rollout datasets | Contact your Fireworks account team to delete these retained artifacts. | | Keep data in your own bucket | Use [BYOB integration](/guides/security_compliance/secure_training/byob) to register an external dataset URL. | | Control encryption of managed data with your own key | Register a [CMEK](/guides/security_compliance/secure_training/cmek) key from your cloud KMS (AWS, Google Cloud, or Azure); revoke it anytime to cut off Fireworks' ability to decrypt. | | Avoid storing a dataset on Fireworks | Use the [Training API](#training-api): no dataset is uploaded or stored; the trainer only receives transient tokenized batches. | | Revoke Fireworks access post-training | Remove the IAM bindings from your bucket after the job completes. | For inference-side controls — disabling Response API storage (`store=False`) or deleting a specific response — see the [Zero Data Retention policy](/guides/security_compliance/data_handling). ## Related Resources How Fireworks handles inference data by default Encrypt managed fine-tuning data with your own KMS key Learn about our comprehensive security measures Full guide to reinforcement fine-tuning Custom training loops that keep your data on your side