A developer-focused guide to OpenAI EKM, external keys, safe testing, and a recovery plan that does not confuse encryption control with an outage.
Encryption projects often begin with a reassuring sentence: “We control the key.” The difficult part starts later, when a key policy changes, a KMS identifier is replaced, or a team needs to explain why a historical response can no longer be read.
OpenAI Enterprise Key Management (EKM) gives eligible organizations a customer-controlled key layer for ChatGPT Enterprise and API data. That can be an important security and compliance control. It also creates a new dependency: your external key-management system now participates in whether some encrypted data can be accessed.
The useful question is not, “Can we turn on EKM?” It is, “Can we prove which project is protected, which features still work, who can change the key path, and what happens when access to that key is removed?”
This guide turns that question into a rollout plan. It is written for the people who own an OpenAI API project, cloud KMS policy, security review, or on-call response. It is not legal advice, and EKM alone does not settle retention, residency, access control, or application-layer data handling.
OpenAI describes EKM as envelope encryption. Your cloud KMS holds a key-encryption key, often called a KEK. OpenAI generates data-encryption keys, or DEKs, to encrypt customer content. The KMS encrypts those DEKs, producing encrypted DEKs that are stored with the encrypted data. To read the data again, OpenAI asks the KMS to decrypt the encrypted DEK.
That distinction matters. The KEK stays outside OpenAI’s systems, but EKM is not the same as keeping all plaintext permanently outside every cloud environment. It is a control over encryption at rest and the authorization path for decrypting the wrapping key. Do not describe it as a substitute for:
That is not a weakness. It is a cleaner design review. Each control should be able to answer one question well. EKM answers, “Which customer-controlled KMS path is required to decrypt encrypted content?”
The sharpest EKM foot-gun is language. “Rotation” often means generating new cryptographic material while keeping the ability to decrypt data protected by older material. “Revocation” means making previously protected material unavailable.
OpenAI’s EKM technical FAQ is explicit: changing the KMS identifier is a revocation, not a benign key rotation. A key cannot decrypt data encrypted under another key. For an API project, the consequences can include losing access to previous batch files, fine-tuned models, or Responses API objects. For a ChatGPT Enterprise workspace, previous conversations, search results, and custom GPTs may become unavailable.
That makes a key change a product and data-governance decision, not a Terraform cleanup. An alias may be useful in a provider-specific lifecycle, but it should never be used to hide the fact that you are testing a destructive access change. Give that action a named owner, a change window, a stop condition, and an explicit decision about historical data.
With EKM, “the application is down” and “the application can no longer read a class of historical data” can be different incidents. Your runbook needs both branches.
Begin with a plain-language decision record. Name the OpenAI organization, the API project or ChatGPT workspace in scope, the cloud KMS account and region, the data classes involved, and the owners for platform, security, privacy, and recovery. State which data is intentionally out of scope.
Then write the hard part: the revocation decision. Who may request it? Who can approve it? What records are expected to become unreadable? How will the application behave if history, files, or fine-tunes cannot be opened? A short answer is better than an implied one.
This document prevents a common failure mode: security believes a key is a generic infrastructure resource, while a product team treats it as an invisible dependency behind user-facing history.
Use a new key for the EKM integration instead of reusing a broadly shared production key. OpenAI’s guidance requires only encrypt and decrypt operations for the integration; it does not need permission to generate data keys. Limit the principal, resource, region, and external identity condition according to the provider-specific documentation.
For AWS, the exact policy and trust relationship must follow OpenAI’s current integration guide. The following deliberately incomplete sketch shows the shape of the review. Treat it as a test fixture, not copy-paste production policy:
{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::OPENAI_ACCOUNT:role/EnterpriseKeyManagement" }, "Action": ["kms:Encrypt", "kms:Decrypt"], "Resource": "arn:aws:kms:REGION:ACCOUNT:key/KEY_ID", "Condition": { "StringEquals": { "sts:ExternalId": "YOUR_OPENAI_ORGANIZATION_OR_PROJECT_ID" } }}
Have a second reviewer compare the deployed policy against the approval, not merely against a template. The evidence should include the exact key ARN or provider equivalent, the OpenAI identity, the allowed operations, the external ID or workload-identity condition, and the policy version.
External keys are managed through OpenAI’s Management API and require an Admin API key with the external-key scopes. That is not an application runtime credential. Keep it out of app containers, CI jobs that ship code, and ordinary developer environments.
A small administrative script can make the boundary obvious:
curl -X POST "https://api.openai.com/v1/organization/external_keys" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $OPENAI_ADMIN_KEY" \ -d '{ "type": "aws", "name": "ekm-sandbox", "role_arn": "arn:aws:iam::123456789012:role/openai-ekm", "kms_arn": "arn:aws:kms:us-east-1:123456789012:key/REPLACE_ME", "external_id": "org-REPLACE_ME" }'
Protect the variables as you would any high-impact organization credential. Log the change ticket, the external-key ID returned by the API, and the approval — not the secret itself. Assign routine model requests to project keys with only the permissions they need.
OpenAI recommends first testing EKM in a new project. Take that literally. Do not turn your busiest project into a proof of concept. Create a small project bound to the registered external key, with a short-lived test key and a narrow dataset that contains no sensitive production information.
Run the exact behaviors your product depends on. A good test packet includes normal Responses calls, the tools you use, files and retrieval if applicable, batch submission and download if applicable, fine-tuning or model artifacts if applicable, streaming, error handling, observability, and administrative workflows. Also test the features your roadmap wants next. OpenAI notes that features not generally available, including beta or alpha features, are unavailable when EKM is enabled.
For every test, record four things: what was attempted, whether it worked, the project ID used, and where its evidence lives. A spreadsheet is fine during a pilot. A versioned test file is better once the control is recurring.
There are two safe drills to practice in a nonproduction project. First, deny the integration permissions temporarily and observe the client-visible error, alert path, KMS audit record, and on-call handoff. Second, follow the documented validation flow for an external key after a controlled change.
Cache-aware behavior matters. The EKM FAQ says DEKs can be cached in memory, so KMS request count will not match message count and an authorization change may not be visible instantly. The lifecycle guide says revocation validation must account for cache expiry. Do not label the drill a pass because an API call failed once. A pass is an evidence bundle: provider audit event, OpenAI validation result, expected application behavior, recovery decision, and a measured time to clarity.
A rollout should leave a compact set of reviewable artifacts. They make later audits faster and make an incident calmer. Keep the packet close to the infrastructure code and change record.
This is intentionally more operational than a compliance checklist. A control is only trustworthy when a different engineer can inspect its evidence, reproduce the safe test, and understand what will break if the key path is cut off.
Monitor both sides of the boundary. On the cloud side, alert on KMS policy changes, identity and trust-policy changes, denied encrypt or decrypt requests, unexpected regions, disabled keys, scheduled deletion, and changes to aliases or versions. On the OpenAI side, restrict and review Admin API key access, external-key changes, project creation, and project-to-key association.
Do not invent a universal KMS-call-to-message ratio. OpenAI documents that in-memory DEK caching and data-access patterns make such ratios unreliable. Instead, establish your own baseline for your test and production workload. Investigate changes that coincide with errors, key events, or unexpected project behavior.
Finally, make the product graceful. If a historical artifact is unavailable because of an intentional key action, show a useful application-level state rather than a raw provider error. If the workload can safely continue without that artifact, say so. If it cannot, fail closed and make the next human action clear.
Most teams test a live request and stop there. That checks only the newest part of the system. An EKM-aware application also has to think about historical objects: saved responses, user-uploaded files, batch artifacts, fine-tuned models, and any internal record that points to them.
Make an inventory with three labels. Reconstructible means the object can safely be regenerated from a source your organization still controls. Recoverable means it can be restored through an approved backup or a retained system of record. Irreplaceable means losing decryption access changes a customer promise, a legal obligation, or a critical workflow. The third category needs the strictest revocation approval.
Then decide how each category behaves. A chat-history screen might hide an inaccessible thread and explain that its encryption access was withdrawn. A workflow that needs a prior file to make a safety decision should not quietly guess; it should stop and ask a human to supply an approved replacement. A batch pipeline may be able to retry a new batch, but only if the input source remains authorized and the duplicate work is safe.
This is also where product owners belong in the key-change meeting. They can identify promises that infrastructure logs do not reveal: an export a customer expects to retrieve, an investigation that requires a trace, or a user-visible history that cannot be reconstructed from the source system. Security owns the control; product owns the consequence; platform owns the recovery path. No single group can make the decision alone.
A clean change request uses three separate verbs. Rotation is planned cryptographic lifecycle work that preserves the ability to read appropriate older data. Revocation intentionally cuts the decrypt path for a key or key reference. Recovery restores an approved path after an accidental denial, provided the organization has decided that restoration is appropriate.
Those verbs should lead to different approval paths. A routine provider-supported rotation may be owned by the KMS team with a standard maintenance procedure. A revocation should require data and product impact review, an exact project or workspace scope, a communication plan, and a check that no broader key sharing will surprise another workload. Recovery should name the time limit, the system of record, and the person authorized to accept the trade-off.
Keep a small decision record alongside the key configuration. Include the intent, the exact external-key or project reference, whether historical data is expected to remain readable, the post-change tests, and the abort condition. That record is more useful than a long policy document during an incident because it answers the immediate question: was this effect expected?
Encryption controls become safer when their deployment resembles a production release. Start with a sandbox project and synthetic data. Move to a low-risk internal workload with a known owner. Then promote one production workload at a time after it passes the same feature and recovery checks. Do not make the promotion rule “the setup API returned success.” Make it “the workload’s feature contract, evidence packet, and failure drill all passed.”
During each stage, compare an EKM project with its non-EKM counterpart only where policy permits. Look for unexpected API errors, missing capabilities, changes in file or batch handling, operational alert noise, and support burden. This is not a benchmark contest. It is a way to discover a behavior difference while the blast radius is small.
A successful rollout finishes with a boring result: users do not notice the encryption layer, reviewers can see the evidence, and the on-call team knows exactly what a key event means. Boring is the right outcome for a control that sits underneath critical data.
EKM is valuable when a customer-controlled key path is a stated requirement and the organization can operate that dependency. It is not a shortcut for an unclear data policy. If your team cannot identify the project owner, the historical-data impact of revocation, or the emergency approver, solve those design problems first.
For a small application with no such requirement, better project separation, access controls, retention decisions, secret management, and logging may reduce more immediate risk. Security controls should make the important things safer without disguising operational debt.
EKM is OpenAI’s customer-controlled encryption-key integration for eligible Enterprise and Edu customers. It uses a customer-managed external KMS key to wrap the data-encryption keys used for encrypted customer content.
No. EKM controls an encryption and decryption path. Retention, deletion, data minimization, access control, and application logging need their own policies and technical controls.
No. OpenAI’s EKM documentation says the integration needs Encrypt and Decrypt permissions. Confirm the current provider-specific instructions before deployment.
OpenAI recommends first testing EKM on a new project. That isolates feature validation and failure drills from live workloads. Existing-project rollout should follow a deliberate, gradual plan.
No. OpenAI describes an identifier change as revocation because a different key cannot decrypt data encrypted under the previous key. Treat it as a potentially destructive availability decision.
OpenAI says DEKs are cached in memory for performance, so KMS traffic depends on cache state, access patterns, and conversation history. Use an application-specific baseline rather than a universal expected ratio.
OpenAI EKM is strongest when it is handled as a living operational control. Create a dedicated key path, bind it to a small test project, prove your product’s real feature set, rehearse an access failure, and preserve the evidence. The goal is not merely to say that you control the key. It is to know, before an incident, what that control changes.
OpenAI Enterprise Key Management: A Rollout Plan That Won’t Lock You Out was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.