Encryption Concepts
High level flow
You control a master key in your cloud which OpenAI never sees
Your master key is used to encrypt data encryption keys (DEKs) used by OpenAI
OpenAI uses the DEKs to encrypt your data at rest. A DEK is encrypted by your master key, generating an eDEK (encrypted DEK), which is stored along with your data
To read the data, OpenAI takes the eDEK, requests your KMS to decrypt it into a DEK, and then decrypts your data
How does EKM encryption work?
Please refer to our article for detailed information: OpenAI Enterprise Key Management (EKM) Overview
Does OpenAI store my DEKs?
No - we store the encrypted DEKs (eDEKs), which are generated by your KMS. To decrypt the data, we ask your KMS to decrypt the eDEK back into the DEK.
Does OpenAI cache my DEKs?
Yes - in memory only. This is for performance to avoid hitting your KMS on every data encrypt/decrypt request. DEKs are never written to storage.
Cloud Permissions
What permissions will OpenAI have on my KMS?
Only the permissions you grant us via the policy you set. We just need at least Encrypt/Decrypt operations. Please also create a new key in your cloud KMS for OpenAI instead of re-using any existing keys that have production purposes.
When does OpenAI get permissions to access my KMS?
All of these steps must have been taken:
You’ve recognized OpenAI's identity (via trust policy, workload identity, etc depending on the cloud provider).
You’ve created a policy for accessing the KMS.
You’ve assigned OpenAI’s identity the permission to access the policy.
If you just create the KMS without taking all of these steps, OpenAI does not have access.
Do I have to store my master key in my cloud?
Nope - it’s up to you how to manage your master key. You can have a cloud-managed solution or an external one where your key is stored separately. OpenAI just needs to call encrypt/decrypt operations on your KMS - how the master key actually performs encrypt/decrypt is an implementation detail opaque to us.
Key Lifecycle
DEK/eDEK Rotation (Controlled by OpenAI)
How often are DEKs/eDEKs rotated?
Every 24 hours on the encryption path (requesting a DEK/eDEK key pair)
Every 1 hour for the decryption key path (DEK -> eDEK)
Do I have to do anything when the DEK changes?
No - DEK/eDEK rotation is done within OpenAI. As long as your master key remains valid, any eDEKs encrypted by your master key can continue to be decrypted into the DEK, which is then used to decrypt your data.
Master Key Rotation and Revocation (Controlled by you)
How often does key rotation and key revocation happen?
This is determined by you since OpenAI does not have visibility into your master key.
What is the difference between key rotation and key revocation?
Key revocation removes access to data encrypted using older keys. Key rotation encrypts data using a new key, but maintains read access to older data.
What happens if I revoke my master key?
If a key is revoked or permissions are removed, the workspace will eventually become non-functional once cached keys expire. At that point, OpenAI can no longer decrypt stored data or encrypt new data. Effectively, the data is “shredded.”
How quickly does revocation take effect?
OpenAI caches DEKs in memory for performance and resilience. Revocation typically takes effect within one hour, once cached keys expire and re-validation fails.
Can revocation be safely tested?
Testing revocation in a production workspace is not recommended because it will permanently render existing data inaccessible. However, customers can (and should) test revocation in a sandbox environment to verify correct behavior and validate their trust assumptions.
If a key is revoked permanently, can the workspace be recovered by attaching a new key?
No. Once the key is lost, the data is irretrievable by design. The only remediation is to spin up a new workspace.
What should we do if a workspace becomes inaccessible due to key changes?
The expected remediation is to create a new workspace. Updating the KMS will not recover existing data.
What is the backout plan if we decide to stop using CMEK?
Currently, there is no backout plan. Once a workspace is created with CMEK, all associated data is encrypted using customer-managed keys and cannot be accessed without them. The only way to discontinue CMEK usage is to create a new workspace — existing encrypted data will remain permanently inaccessible.
What happens when I rotate my master key?
New cryptographic material will be generated for encryption so new encryption requests will use the new key. However, the KMS identifier (ARN or key name) remains the same and old data is still decryptable. Many cloud providers offer automatic key rotation (AWS, GCP, Azure).
Does OpenAI re-encrypt older data re-encrypted when I rotate my master key?
No. The new cryptographic material will only be used to encrypt new data.
How long does it take for a key rotation or key revocation to take effect?
1 hour. This is because the DEK/eDEKs are cached in-memory and we re-validate these entries with your KMS hourly.
Switching the KMS Identifier
Is switching the KMS identifier a key revocation or key rotation?
Key revocation. One key cannot decrypt data encrypted by another key.
Can OpenAI help me switch my KMS identifier for a ChatGPT workspace?
If you confirm that the intention is to revoke your key, we can help you do this for a ChatGPT workspace. Note that when the KMS ARN is updated, older data will remain inaccessible, so you will end up with a mix of inaccessible and accessible data after the change.
Can OpenAI help me switch my KMS identifier for an API project?
If you're using the API, the API makes it easy to archive and create new projects, so please instead archive the project whose data is not accessible anyway, register a new EKM config with OpenAI, and create a new API project with the new KMS key.
What if I want to regularly switch my KMS identifier by myself?
This is not recommended since you probably do not want to regularly revoke your key. However, you can still do this if you use a cloud provider that supports a KMS key alias (AWS example). You can register that KMS key alias with OpenAI, and then on your cloud provider you can swap out the underlying KMS identifier pointed to by the alias at any time to issue a key revocation.
Beta vs. GA Behavior
Are there any known risks or system-level changes when using the encryption beta in production?
The beta environment is functionally equivalent to GA, and no migration steps are expected. The primary risk is that some edge-case features may not yet support encrypted content due to incomplete code paths. These are rare and actively being resolved. Data is fully encrypted and protected regardless of these potential issues.
Will there be any migration steps from beta to GA?
No. Workspaces using the encryption beta will automatically be supported in GA without any user action.
Additional Technical Details
Envelope Encryption & Permissions
Do we need to grant GenerateDataKey permissions to OpenAI for EKM?
No. OpenAI only requires Encrypt and Decrypt permissions on your KMS key. The GenerateDataKey permission is not necessary for EKM integration.
Does OpenAI use envelope encryption for customer data?
Yes. OpenAI uses an envelope encryption model:
Customer KMS: Manages the Key Encryption Keys (KEKs). OpenAI never sees or stores the KEKs.
OpenAI Infrastructure: Generates and manages Data Encryption Keys (DEKs). Each DEK is encrypted (wrapped) with your KEK before storage.
Data Flow:
Customer data is encrypted with a DEK.
That DEK is encrypted with your KEK, producing an eDEK.
The eDEK is stored alongside the encrypted data.
To decrypt data, OpenAI requests your KMS to decrypt the eDEK, retrieves the DEK, and decrypts the content.
Why did OpenAI choose this model over letting KMS manage both KEKs and DEKs?
There are two common envelope encryption approaches:
KMS-Managed KEKs and DEKs:
Pros: Simpler implementation, no need to maintain encryption infrastructure.
Cons: Every encryption/decryption request hits the KMS, increasing latency, cost, and introducing a single point of failure.
KMS-Managed KEKs / OpenAI-Managed DEKs (Our Approach):
Pros: Significantly lower latency and cost, better scalability and reliability, and continued operation during partial KMS outages (up to the DEK cache TTL).
Cons: Slightly more complex implementation on OpenAI’s side.
This design allows OpenAI to provide strong security guarantees while minimizing operational risk and cost to customers.
How often are DEKs rotated?
Each DEK is rotated approximately every 60 minutes. This provides temporal isolation — even if a DEK were somehow compromised, the impact would be limited to data encrypted within that one-hour window.
KMS Request Volume & Observability
We see far fewer KMS requests than the number of user messages. Should these numbers match?
No, they will not correlate directly.
Because OpenAI caches DEKs in memory for performance reasons, KMS calls are only made when a DEK needs to be decrypted — not on every encryption or decryption operation. As a result, you should expect:
Fewer KMS requests than user interactions.
Occasional spikes when cached DEKs expire (about every hour) or when older encrypted data needs to be accessed.
Additional calls when retrieving historical data, such as when a user continues a long-running conversation and older DEKs must be loaded.
The exact number of KMS requests depends on caching state, user behavior, data access patterns, and conversation length, and therefore will not directly correlate with message volume.