DuoKey

OpenAI EKM

Encrypt your OpenAI data with a key you control

Register your own AWS KMS, Azure Key Vault or Google Cloud KMS key with OpenAI Enterprise Key Management. DuoKey handles the grant, the registration and the status checks. The key never leaves your cloud.

Request a demo→See how it works

The problem

Your prompts and files sit under a key you do not hold

By default, the provider that stores your AI data also controls the key that protects it.

Teams now paste contracts, source code and customer records into ChatGPT Enterprise and the OpenAI API. Without a customer-managed key, you cannot prove custody to an auditor or switch access off on your own terms. OpenAI EKM fixes that, but only if the key is granted, registered and checked correctly.

  • Provider-held key

    Encryption keys stay with the AI provider unless you bring your own.

  • Per-cloud grants

    AWS key policies, Azure roles and Google WIF each have their own traps.

  • Silent drift

    A grant removed or a key revoked goes unnoticed until something breaks.

  • Audit evidence

    Reviewers ask where the AI data key lives and who can turn it off.

How it works

DuoKey registers the key. OpenAI uses it directly in your cloud.

OpenAI wraps its Data Encryption Keys with your Key Encryption Key (KEK) and calls your cloud KMS whenever it encrypts or decrypts. DuoKey sets this up through OpenAI's Management API, then tracks it.

Registration · once per key, through DuoKey

DuoKey Cockpit

Holds the sealed Admin API key

OpenAI Management API

Receives the KEK coordinates

External key id

Assigned by OpenAI

Runtime · DuoKey is not involved

OpenAI

Needs to encrypt or decrypt

Your cloud KMS

Wraps and unwraps the DEK

Your KEK

Never leaves your account

DuoKey is not in the data path: it never wraps or unwraps OpenAI's keys, and your KEK never transits through DuoKey.

Multi-cloud

Keep the KEK in the cloud you already run

Each provider needs a different grant. Cockpit shows the exact instructions with your organization id already filled in, so the grant is right on the first try.

AWS KMS

Key policy statement

Lets OpenAI's EKM IAM role call Encrypt and Decrypt on your KEK, only when sts:ExternalId matches your organization id.

Registered with: the KMS key ARN

Azure Key Vault

Service principal + role

Create OpenAI's service principal, create an RSA key, then assign Key Vault Crypto User on that key only.

Registered with: vault URI and key name

Google Cloud KMS

Workload Identity Federation

A pool and OIDC provider with your organization id as audience, granted CryptoKey Encrypter/Decrypter on the KEK.

Registered with: the key resource

Setup

From Cockpit to a registered key in five steps

  1. 01

    Create the app

    In Cockpit, open Apps, then Create new app, then OpenAI EKM. One app per OpenAI organization.

  2. 02

    Organization

    Name the app and enter your OpenAI organization id (org-…).

  3. 03

    Admin API key

    Paste an organization Admin key. It is stored sealed and never returned by the API once saved.

  4. 04

    Apply the grant and register

    Pick the cloud, apply the grant, enter the key coordinates. DuoKey submits them to OpenAI.

  5. 05

    Activate in OpenAI

    Once the key is registered, activate it on the OpenAI projects that should use it.

Lifecycle

Know at any time whether your key is still in place

Every registered key has a status, and you can re-check it with OpenAI whenever an auditor asks.

  • draftCreated, not yet submitted
  • registeredAccepted by OpenAI, external key id assigned
  • errorRejected, with the reason to fix the grant
  • revokedNo longer in OpenAI's external key list

Validate

Confirm the key is still registered with OpenAI.

Test connectivity

Check the stored Admin key reaches the Management API.

Rotate the Admin key

Replace it without losing any registration.

De-register

Remove the key from OpenAI, then the local record.

To cut OpenAI's access, remove the grant

De-registering in DuoKey does not stop OpenAI from using the key. Remove the IAM permission, role assignment or federation binding on your KMS: per OpenAI's design, access stops within about an hour.

Requirements

What you need

Read the setup guide
  • An OpenAI Enterprise organization with EKM available
  • An organization Admin API key from the OpenAI platform settings
  • A KEK in AWS KMS, Azure Key Vault or Google Cloud KMS (or the right to create one)
  • Permission to edit IAM policies, role assignments or Workload Identity Federation on that account

Deep dives

Field guides for your programme

What Is BYOK? Bring Your Own Key Encryption Explained

BYOK explained for security and risk leaders: when customer-held keys reduce cloud concentration risk and when provider-managed encryption is not enough.

Read guide

Hold Your Own Key (HYOK): How It Works, BYOK vs HYOK, and Where It Applies (2026)

Hold your own key (HYOK) explained: BYOK vs HYOK vs provider-managed keys, how Microsoft 365 DKE, AWS XKS and Google CSE implement it, and how to choose.

Read guide

Engagement

Bring your own key to OpenAI, without a new key path

See OpenAI EKM registered against your own cloud KMS key, with grant instructions, status tracking and on-demand validation in Cockpit.

Request a demo

Discuss the decisions that matter most to your security programme.

Tell us where control is difficult today. We will help you identify a practical next step.

Book a callSee the platform