Can A Customer-Managed Key Stop An AI Provider From Decrypting Chats?
A customer-managed key can improve control, auditability, and revocation, but it does not automatically stop an AI provider from decrypting chats during service operation.
Usually, no. A customer-managed key can give an organization meaningful control over key policy, auditing, rotation, and revocation, but it does not automatically prevent an AI provider from decrypting chat data while the service is operating. If the provider's authorized service identity can ask the customer's key-management system to unwrap or decrypt a data key, the provider can generally use the resulting plaintext for the permitted workflow.
Watch The 30-Second Summary
That can still be a valuable security model. It is simply different from client-side encryption, end-to-end encryption, or a provider-blind design in which the service cannot obtain the plaintext.
Who This Guide Is For
This guide is for:
- security and privacy teams evaluating enterprise AI products
- buyers comparing customer-managed key, bring-your-own-key, and external key-management claims
- administrators deciding whether key revocation is an effective emergency control
- legal and procurement teams translating an encryption claim into an actual data path
- technical leaders who need to distinguish encryption at rest from protection during AI inference
- people choosing between hosted AI, confidential computing, client-side tools, and local models
The most useful question is not, "Who owns the key?" It is, "Which identities can cause plaintext to be produced, where does that happen, and for how long?"
The Short Answer: Key Ownership And Plaintext Access Are Different
Most hosted services encrypt stored data with a data-encryption key. That key may itself be protected by a customer-controlled key-encryption key in AWS KMS, Azure Key Vault, Google Cloud KMS, or another supported system.
When the application needs the stored data, a common server-side flow looks like this:
- the provider stores encrypted chat data and an encrypted data key
- the provider's service identity sends the encrypted data key to the customer's key-management service
- the key-management service checks policy and authorization
- if allowed, it returns an unwrapped data key or performs the necessary cryptographic operation
- the provider uses that result to decrypt the chat inside its service environment
- the provider processes the plaintext and may keep an operational key in memory for a limited period
The customer can control whether the request is authorized. The customer may also receive key-use logs and be able to revoke access. But while access is authorized, the provider's application can still receive or derive what it needs to decrypt the data.
| Model | Who controls key policy? | Can the hosted service normally obtain plaintext? | Main value |
|---|---|---|---|
| Provider-managed encryption | Provider | Yes | Baseline encryption at rest |
| Customer-managed key or BYOK | Customer controls or hosts a key used by the service | Usually yes, while authorized | Audit, separation of duties, revocation, compliance control |
| Client-side encryption | Customer device or trusted client | Not before upload | Provider stores ciphertext, but cannot run an ordinary cloud AI model over that plaintext |
| End-to-end encrypted communication | Endpoints | Intermediary generally cannot | Private transport between endpoints |
| Provider-blind AI processing | Customer-controlled boundary or specialized protected execution | Designed to restrict provider access | Compute on sensitive content with stronger technical isolation |
These terms are not interchangeable. A product can truthfully advertise customer-managed keys without claiming that its service is cryptographically unable to access plaintext.
What Current Provider Documentation Shows
Features and architecture can change. These sources were checked on July 24, 2026.
OpenAI Enterprise Key Management
OpenAI's Enterprise Key Management overview describes a customer-controlled key-encryption key while OpenAI manages the data-encryption keys used for customer content. The customer grants OpenAI permissions to use the external key for encryption and decryption operations.
The more detailed OpenAI EKM Technical FAQ describes the important data path: OpenAI requests the configured key-management service to unwrap an encrypted data-encryption key and then uses the resulting key to decrypt the data. OpenAI also documents in-memory caching of decrypted data keys for operational performance.
That is useful customer control, not provider blindness. The customer can restrict or revoke the key, but OpenAI can decrypt protected content while the necessary permission remains available.
OpenAI's key-lifecycle documentation also separates rotation from revocation. Rotating a key changes its version without necessarily blocking the service. Revocation is the action intended to stop access, and a service may remain functional only after the relevant cached keys expire.
Azure OpenAI And Azure Key Vault
Microsoft describes customer-managed keys for Azure OpenAI as an additional layer of server-side encryption at rest. In the current Azure OpenAI encryption documentation, an Azure OpenAI managed identity receives the Key Vault permissions needed to use the customer key.
The customer manages the key and can disable or revoke it. During normal authorized operation, Azure's service identity can still use the key path required to encrypt and decrypt stored data. The control changes who governs key access; it does not move normal AI inference into the customer's browser.
Microsoft's broader encryption-model guidance draws the relevant contrast: with client-side encryption, data is encrypted outside Azure and the resource provider receives an encrypted blob rather than the plaintext and keys.
Google Cloud CMEK
Google's customer-managed encryption key documentation likewise describes a service agent that is granted the Cloud KMS encrypter/decrypter role. Google services can then transparently encrypt and decrypt the protected resource on the customer's behalf.
The organization controls the key and its policy. The service agent remains an authorized cryptographic actor. That is why a CMEK claim alone does not answer whether the service can see plaintext.
What A Customer-Managed Key Actually Gives You
A well-implemented customer-managed key can provide real benefits.
An Independent Access Switch
The customer may be able to disable or revoke the key without waiting for the application provider to delete each record. This can be useful during offboarding, an incident, a contract dispute, or an access-policy change.
Revocation is not the same as deletion. Encrypted data can remain stored, and service behavior may depend on cached keys, backups, replicas, or documented recovery paths.
Key-Use Audit Records
The customer's key-management system can record requests made against the key. These records can help answer which service identity used the key, when it happened, and whether the request was permitted.
A key log does not necessarily record every employee view, model operation, cache access, or plaintext copy after a key was successfully unwrapped. It covers the cryptographic operation visible to that key service.
Separation Of Duties
The application provider can store ciphertext while the customer or a different cloud account controls the key policy. An attacker may then need to compromise more than one boundary.
The benefit depends on permissions. If one identity can freely modify both the application and the key policy, the practical separation is weaker.
Customer-Controlled Rotation And Policy
The customer can apply its own rotation schedule, region restrictions, approval process, logging destination, and administrative controls when supported.
Rotation usually replaces or versions the wrapping key. It should not be described as an immediate plaintext-access cutoff unless the provider specifically documents that behavior.
A Stronger Contract And Incident-Response Control
Customer key custody can make responsibilities more explicit. It can also create a verifiable operational control for regulated buyers.
That is worthwhile even when the provider can decrypt during ordinary service operation. The accurate claim is "customer-controlled key authorization," not "the provider can never read the data."
Why An AI Service Normally Needs Plaintext
A conventional language model consumes readable tokens or another meaningful representation of the prompt. If a browser sends only opaque ciphertext and no trusted component on the provider side can decrypt it, the ordinary hosted model cannot understand the request.
This creates a basic design choice:
- decrypt inside the provider's normal service boundary
- decrypt and process on the customer's device or infrastructure
- decrypt inside a specially isolated execution environment with attestation and restricted operators
- use a more specialized cryptographic technique that can compute over protected data, with significant capability and performance tradeoffs
Customer-managed encryption at rest usually chooses the first option. It can reduce risks around stored media and unauthorized key use, but the prompt becomes plaintext somewhere in the provider's processing path.
What Provider-Blind Processing Would Require
If the goal is to make the AI provider technically unable to read chat content, ask for an architecture that addresses data in use, not only data at rest.
Possible approaches include:
Client-Side Or Local Inference
The prompt stays on the device and a local model processes it. This offers a clear provider-blind boundary, but the user must supply hardware, model storage, updates, and security.
Customer-Hosted Inference
The organization runs the model in its own environment. This can move plaintext outside the vendor's normal service boundary, but administrators, infrastructure vendors, and any connected tools remain part of the trust model.
Attested Confidential Computing
The model runs in a hardware-protected environment that can release a decryption key only after verifying approved code and configuration. This can restrict cloud operators, but buyers still need to examine attestation, side channels, logging, outbound connections, update authority, and who defines the trusted code.
Specialized Privacy-Preserving Computation
Techniques such as fully homomorphic encryption, secure multiparty computation, or split processing can narrow plaintext exposure. They are not a drop-in description for ordinary large-model inference. Ask which exact data, operations, model features, and performance limits the product supports.
End-To-End Encrypted Human Communication
End-to-end encryption can prevent an intermediary from reading a message exchanged between people. A hosted AI model is itself a processing endpoint. If the provider operates that endpoint and it receives plaintext, calling the transport end-to-end encrypted does not by itself make the provider blind.
Seven Questions To Ask An AI Vendor
Use these questions during a security review:
- Which exact data is covered? Prompts, outputs, files, embeddings, indexes, backups, logs, feedback, and abuse-monitoring records may have different paths.
- Where is plaintext produced? Ask for a sequence diagram from the client through storage, inference, tools, and logging.
- Which identity can unwrap or decrypt? Get the service principal, role, permissions, and policy conditions.
- Are decrypted keys cached? Ask for cache location, maximum lifetime, invalidation behavior, and what happens after revocation.
- What does rotation do? Determine whether it merely creates a new version or actually interrupts old-data access.
- What survives revocation? Consider active sessions, plaintext caches, replicas, backups, telemetry, generated outputs, and previously exported data.
- Can the vendor's staff or software change the trusted path? Review administrative access, code deployment, support tooling, incident access, attestation, and audit evidence.
A useful answer should identify actors and data flows. "Your data is encrypted with your key" is not enough by itself.
Common Claims That Need More Precision
"The Vendor Never Has Your Key"
The vendor may never receive the long-lived customer key material and still be authorized to ask the key-management system to unwrap data keys. Key possession and key use are different.
"You Can Revoke Access At Any Time"
Ask how quickly revocation affects new decryptions, cached keys, active requests, background jobs, and backups. "At any time" may describe the control surface, not instantaneous elimination of every plaintext path.
"All Customer Data Uses CMK"
Verify the scope. Some systems exclude metadata, search indexes, system logs, safety records, telemetry, derived data, or third-party integrations.
"The Data Is Encrypted End To End"
Identify both ends. If one end is the provider-operated model service, the provider may still process plaintext at that endpoint.
"Key Rotation Blocks Access"
Rotation commonly preserves service access while introducing a new key version. Revocation or disabling is the more relevant access-stop test.
Where OpenVeil Fits
OpenVeil is a paid, privacy-focused AI chat workspace with browser-local history and no server-side chat-history record for normal private chat sessions. OpenVeil does not use prompts, uploaded files, images, audio, selected local-history context, or AI outputs to train foundation models.
This is a data-minimization and history-storage choice, not a claim that customer-managed keys make OpenVeil or its providers unable to process active prompts. Active requests may still be processed by OpenVeil and necessary AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers. Account, billing, security, and operational records are separate from browser-local private-chat history.
If your requirement is fully local inference, a customer-hosted model, or cryptographic provider blindness, verify that architecture directly. OpenVeil should not be described as fully offline or as a replacement for a specialized enterprise confidential-computing system.
Read the OpenVeil privacy policy and What To Check Before Trusting Any AI Privacy Claim. If browser-local history and hosted AI convenience fit your needs, create an OpenVeil account.
Frequently Asked Questions
Does BYOK Mean The AI Provider Cannot Read My Chats?
Usually, no. In many BYOK or customer-managed-key designs, the provider's service identity is authorized to use the customer key to unwrap a data key. The provider can then decrypt content for the service while that authorization remains active.
Does A Customer-Managed Key Protect Chat Data At Rest?
It can add customer-controlled protection for covered stored data. Confirm which records are in scope, including prompts, outputs, uploaded files, embeddings, indexes, backups, logs, and feedback copies.
Can Key Revocation Immediately Stop An AI Provider?
It can stop new authorized key operations, but the effect may not be instantaneous everywhere. Providers may document short-lived in-memory key caches, active requests, backups, or recovery behavior. Test and contract for the expected revocation window.
Is Key Rotation The Same As Revocation?
No. Rotation normally introduces a new key version while preserving authorized access. Revocation or disabling is intended to stop use.
Is Client-Side Encryption Better?
It solves a different problem. Client-side encryption can prevent the provider from decrypting stored content, but a normal hosted AI model cannot process opaque ciphertext. The system needs local inference, customer-hosted inference, protected execution, or another supported privacy-preserving design.
Can A Provider Use My Data After The Key Is Revoked?
Revocation can block access to ciphertext that still requires the key. It cannot retroactively erase plaintext already processed, exported outputs, independently retained operational records, or data outside the key's documented scope.
What Is The Best One-Sentence Procurement Test?
Ask: "Can your service identity obtain plaintext while my key is enabled, and what exact data remains accessible after I disable it?"
Bottom Line
A customer-managed key can give you stronger control without making the AI provider blind. It can improve auditability, separation of duties, incident response, and the ability to revoke future decryption. During normal authorized operation, the provider may still unwrap a data key and process plaintext.
If provider inability to read chats is the requirement, evaluate client-side or local processing, customer-hosted inference, attested confidential computing, or another architecture that protects data in use. Judge the system by its actors, permissions, caches, and plaintext path—not by who owns the key label.