Skip to main content
With Customer-Managed Encryption Keys (CMEK), you bring an encryption key from your own cloud KMS — today, AWS KMS — and Fireworks uses it to encrypt the data your managed fine-tuning jobs read and write. Your key controls access to your data at rest: revoke it and Fireworks can no longer decrypt your datasets or checkpoints. Calls Fireworks makes to your key are recorded in your own cloud’s audit log.
Fireworks never stores your root key. Each fine-tuning resource gets a unique data key that is encrypted (“wrapped”) by your KMS key and stored only in wrapped form. The unwrapped key exists only briefly in memory during a job and is then discarded.

​
How it works

CMEK uses envelope encryption:
  1. You create a key (your key-encryption key, or KEK) in your own cloud KMS and grant Fireworks permission to call Encrypt and Decrypt on it — nothing else.
  2. The first time a job, dataset, or checkpoint needs encryption, Fireworks generates a unique 256-bit data-encryption key (DEK) for that resource and immediately wraps it with your KEK. Only the wrapped key is persisted.
  3. Fireworks encrypts your artifacts locally with AES-256-GCM before they are written to storage.
  4. To read the data back, Fireworks asks your KMS to unwrap the DEK. That call — and every call — is logged in your cloud’s KMS audit trail. Unwrapped keys are cached briefly (about 5 minutes) and then discarded, so subsequent reads re-validate against your KMS.
Because access to your data depends on your KMS answering an unwrap request, you stay in control: disable or revoke the key and the data becomes unreadable.
During an active fine-tuning job, training compute processes your data in plaintext in memory — that is inherent to training a model on it. CMEK controls access to your data at rest (datasets, checkpoints, and logs), not the in-memory computation during the job itself.

​
What CMEK protects

CMEK covers the durable artifacts your fine-tuning jobs read and write:
  • Training and evaluation datasets you upload
  • Intermediate checkpoints and distributed-checkpoint shards
The following are governed by separate operational and contractual controls rather than your key:
  • Job metadata (job names, hyperparameters, status) stored in the Fireworks control plane
  • Transient scratch data that exists only for the duration of a job and is destroyed when the job ends
CMEK currently supports Supervised Fine-Tuning (SFT). Support for Direct Preference Optimization (DPO) and Reinforcement Fine-Tuning (RFT) is coming soon. Today, CMEK covers the datasets and intermediate checkpoints your jobs read and write. Encrypting final model weights with your key, and deploying a model whose weights were encrypted with your key, is also coming soon. Encrypting inference requests and responses with your key is not part of CMEK today.

​
Supported KMS providers

CMEK currently supports AWS KMS. Fireworks needs only Encrypt and Decrypt on your key, and authenticates with short-lived, federated credentials.
CloudKMSHow Fireworks authenticates
AWSAWS KMSIAM role assumed via OIDC web-identity federation
Support for Azure Key Vault and Google Cloud KMS is coming soon.

​
How Fireworks authenticates

Fireworks reaches your cloud from a single federated identity — a Google-issued OIDC identity that the managed fine-tuning service runs as. You configure your cloud’s IAM to trust that identity through federation (for AWS, web-identity federation into an IAM role) and to allow it Encrypt/Decrypt on your key. Three properties follow from this design:
  • 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 to reach your KMS — it calls your KMS’s API from Fireworks infrastructure, as the identity you authorized.
  • Scoped to your account. The token Fireworks presents when it authenticates carries your Fireworks account ID as its audience, and you configure your federation trust to accept only that audience. A token issued for any other account is rejected by your cloud — so cross-tenant access is blocked by your own infrastructure, not just by Fireworks.
To configure trust, you use the Fireworks identity below, scoped to your own account as the token audience:
ValueIdentifier
OIDC issuerhttps://accounts.google.com
Fireworks identity (subject)108606366655288854355
Token audience<YOUR_FIREWORKS_ACCOUNT_ID>
The issuer and subject are published by Fireworks (stable per environment); the audience is your own Fireworks account ID.
Grant only Encrypt and Decrypt on the specific key. CMEK never needs to export key material, and never needs administrative permissions on your key.

​
Setup

1

Create or choose a key in your KMS

Create a symmetric encryption key in your cloud KMS (or pick an existing one). One key per Fireworks account is sufficient — Fireworks derives a unique data key per resource underneath it.
  • AWS KMS — a symmetric KMS key in your account and region.
2

Grant Fireworks Encrypt/Decrypt on the key

Authorize the Fireworks identity to call Encrypt and Decrypt on your key. You grant access to the federated identity — you never share a secret.
Create an IAM role the Fireworks identity can assume via web-identity federation, and allow that role Encrypt/Decrypt on your key. You do not need to register an OIDC identity provider — accounts.google.com is a built-in federated principal in AWS STS.Trust policy on the role, locked to the Fireworks identity:
{
  "Effect": "Allow",
  "Principal": { "Federated": "accounts.google.com" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "accounts.google.com:sub": "108606366655288854355",
      "accounts.google.com:oaud": "<YOUR_FIREWORKS_ACCOUNT_ID>"
    }
  }
}
The sub condition locks assumption to the Fireworks identity; the oaud condition pins the token’s audience to your Fireworks account, so a token issued for any other account is rejected.AWS KMS authorizes against both IAM and the key policy, so grant kms:Encrypt and kms:Decrypt on the specific key in both the role’s permissions policy and the key policy.You’ll register the account ID, region, key ARN, and role ARN with Fireworks in the next step.
3

Register the key with your Fireworks account

Register the key — together with the identity references you gathered above — on your account. You register one key per account.
firectl account external-keys create \
  --cloud aws \
  --kms-key "<YOUR_KMS_KEY_RESOURCE_ID>"

firectl account external-keys list
Also pass the identity references from the AWS tab above (for example, --role-arn).Once a key is registered, encryption is automatic — your data is encrypted at rest with your key, and uploads through firectl and the SDKs are encrypted client-side, so plaintext never leaves your environment. Keep your firectl / SDK up to date.
4

Verify

Run a small fine-tune (below) and confirm Encrypt / Decrypt calls appear in your cloud’s KMS audit log.

​
Running a CMEK fine-tune

Once your key is registered, fine-tuning works exactly as it does today — encryption and decryption are transparent. 
# Upload a dataset (encrypted client-side with your key)
firectl dataset create {DATASET_NAME} --file ./data.jsonl

# Launch a supervised fine-tuning job
firectl sftj create \
  --dataset "accounts/{ACCOUNT}/datasets/{DATASET_NAME}" \
  --base-model "accounts/fireworks/models/{MODEL}" \
  --output-model {TRAINED_MODEL_NAME}
Encrypting the resulting model’s final weights with your key — so downloads decrypt transparently and you can deploy the model on Fireworks with your key — is coming soon.

​
Rotating and revoking your key

CMEK respects the lifecycle controls your KMS already gives you.
  • Key-version rotation — When you create a new version of a key in your KMS, new data is wrapped with the new version automatically and existing data keeps working. No action is needed on the Fireworks side, and your data is never re-encrypted.
  • Rotating the registered key (planned) — Changing the key registered with your account isn’t supported yet; today you set one key at registration. We expect to support registering additional keys and promoting a new primary — so new data wraps under the new key while previously registered keys keep older data decryptable — in a future release.
  • Revocation — Revoke the grant, disable the key, or schedule it for destruction in your KMS. In-flight jobs holding a cached key continue until the cache expires (about 5 minutes), then fail closed. New jobs fail immediately.
  • Re-grant — Restore the grant or re-enable the key and access resumes; new jobs work right away.
Disabling or destroying your key makes the data encrypted under it permanently unrecoverable by Fireworks — by design. Likewise, if your KMS is unreachable for longer than the key cache window, in-flight jobs will fail.

​
Auditing

Every Encrypt and Decrypt call Fireworks makes against your key is recorded in your cloud’s native audit log — AWS CloudTrail — including the calls that fail after you revoke access. You hold the authoritative record of when and how your key was used.

​
Limitations

  • CMEK currently supports AWS KMS. Support for Azure Key Vault and Google Cloud KMS is coming soon.
  • Encrypting final model weights with your key — and deploying a model whose weights were encrypted with your key — is coming soon. Today CMEK covers your datasets and intermediate checkpoints.
  • During an active job, compute processes your data in plaintext in memory; CMEK protects data at rest, not in-memory computation.
  • Encrypting inference requests and responses with your key is not part of CMEK today.
  • Uploads must go through firectl or the SDKs, which encrypt client-side before data leaves your environment. The web-console upload path doesn’t perform that client-side encryption yet, so it isn’t supported on CMEK-enabled accounts. (Planned: web-console upload support is expected in a future release.)
  • Changing the registered key is not supported yet — you register one key per account at registration time. (Planned: rotating to a new registered key is expected in a future release.)
  • Job metadata and transient scratch data are covered by separate operational and contractual controls, not your key.

Secure Training (BYOB)

Keep datasets and models in your own cloud storage

Data Security Overview

Learn about our comprehensive security measures