Who Holds The Encryption Keys For An AI Chat?
The answer depends on the layer: a provider often manages transport and storage keys, a customer-managed key can add lifecycle control, and only a true client-side design keeps plaintext away from the service.
There is no single encryption key for an AI chat. A typical hosted AI service uses different keys for network connections, databases, backups, logs, and internal services. In most consumer products, the provider or its infrastructure platform manages those keys and can authorize the service to decrypt data when needed.
Watch The 30-Second Summary
Customer-managed keys can add meaningful control over stored data, but they do not automatically make model processing end-to-end encrypted. To evaluate an AI privacy claim, ask who can authorize decryption at each stage and where plaintext must exist for the service to work.
The Short Answer: Key Control Depends On The Layer
| Layer | Common key holder or controller | What the encryption protects |
|---|---|---|
| Browser-to-service connection | Browser and service endpoint negotiate session keys | Data moving across the network |
| Service database or object storage | Provider or cloud platform by default | Stored disks, database files, snapshots, and backups |
| Customer-managed encryption key | Customer controls policy; service receives authorized cryptographic access | Selected stored resources and key lifecycle |
| External key manager or HSM | Customer or third-party key operator | Stronger separation of key custody, where supported |
| Client-side or end-to-end encryption | User device or intended endpoints | Content from intermediaries that never receive a decryption path |
These models are not interchangeable. A service can truthfully say "encrypted in transit and at rest" while still being able to process, display, moderate, search, retrieve, or disclose authorized plaintext.
Start With The Threat Model
Encryption is not a magic privacy label. It is a control against specific threats.
Encryption in transit helps prevent a network observer from reading traffic between the browser and the service endpoint. Encryption at rest helps protect stored media or database copies from being read without the key. Key-management controls limit which identities, services, and administrators can perform cryptographic operations.
None of those statements alone answers whether the AI provider can see the content during normal operation. If the provider's server receives the prompt in plaintext and sends it to a model, the provider is an authorized endpoint even when transport and storage are strongly encrypted.
The practical buyer question is therefore:
Which systems can cause this content to be decrypted, for what purpose, under whose authority, and with what audit trail?
Provider-Managed Keys
Provider-managed or platform-managed encryption is the default for many cloud services. The platform generates, stores, rotates, backs up, and uses the keys. This reduces configuration mistakes and protects stored infrastructure without requiring the customer to run a key-management program.
Microsoft's current Azure encryption-at-rest documentation describes platform-managed keys as the default and says the platform handles generation, storage, rotation, and backup. Google Cloud likewise says it encrypts customer data at rest by default with Google managing the keys.
This is real security. A stolen disk or copied database cannot normally be restored elsewhere without the keys. But the platform and authorized service workloads retain the ability to use those keys. Provider-managed encryption therefore does not mean the provider is technically unable to decrypt data.
Customer-Managed Keys
Customer-managed keys, often called CMK or CMEK, let an organization control a key policy or key-encryption key used by a compatible service. Depending on the platform, the customer may control:
- key creation or import
- storage region and protection level
- which service identities can use the key
- rotation schedule
- enable, disable, and destruction actions
- logs of key administration and cryptographic use
- separation between application administrators and key administrators
Google Cloud's current CMEK documentation says the customer can control location, access, rotation, use, and destruction. It also explains an important operational detail: the integrated service uses a service agent with encrypt/decrypt permission. The service can process the resource while that permission and the key remain active.
That means customer-managed keys provide control without necessarily preventing the service from seeing plaintext. They can support offboarding, revocation, auditability, regulatory requirements, and a cryptographic boundary around stored resources. They are not automatically client-side encryption.
External Keys And Hardware Security Modules
Some enterprise platforms support external key managers or hardware security modules. These can keep key material outside the application's ordinary infrastructure and require a controlled service to approve cryptographic operations.
This separation can reduce the impact of a compromise and make key use more observable. It can also create availability risk: if the key service is unreachable or authorization is revoked, protected data may become inaccessible.
NIST Special Publication 800-57 Part 1 treats key management as a lifecycle covering generation, distribution, storage, access, use, rotation, compromise handling, recovery, archival, and destruction. The lesson is broader than where the key file sits. A secure design needs policy, roles, inventory, cryptoperiods, audit, and recovery.
Client-Side And End-To-End Encryption
Client-side encryption means content is encrypted before it reaches the service's storage or processing layer. End-to-end encryption goes further: only intended endpoints hold the keys needed to read the content.
That can prevent an intermediary from reading stored content, but it creates a basic design constraint for hosted AI: a server-side model cannot generate an answer from plaintext it is technically unable to obtain.
A system can address that constraint in several ways:
- run the model locally on the user's device
- run computation inside a separately attested confidential-computing environment
- decrypt only inside a customer-controlled environment
- use specialized privacy-preserving cryptography with substantial capability and performance limits
- provide end-to-end encryption for history while separately transmitting an active prompt for model processing
Each architecture has different guarantees. Do not infer end-to-end encryption from a padlock icon or the phrase "encrypted at rest."
Envelope Encryption: Why There Are Usually Several Keys
Cloud services commonly use envelope encryption. Data is encrypted with a data-encryption key. That key is then protected by a key-encryption key stored in a key-management system.
The pattern makes rotation and large-scale storage practical. It also clarifies why "we hold our own key" can be incomplete. Ask:
- Which key does the customer control?
- Can the service identity ask the key manager to unwrap data keys?
- Are active keys cached in service memory?
- What resources are outside the customer-managed-key scope?
- Are logs, search indexes, previews, and backups covered?
- What happens to already decrypted or derived data after revocation?
Microsoft's Azure documentation notes that customer-managed key revocation can make dependent encrypted resources inaccessible, while operational services may use protected cached keys for availability and performance. Product-specific behavior must be verified rather than generalized from the label.
The Key-Custody Audit
1. Map Every Data State
List where the chat can exist:
- browser memory and local storage
- network connection
- application gateway
- model router
- model provider
- primary database
- file or object storage
- search or retrieval index
- cache
- logs and traces
- backups
- analytics or safety review systems
One encryption statement rarely covers all of them.
2. Name The Authorized Decryptors
For each state, identify the principals that can cause decryption:
- user device
- application service account
- model service
- cloud storage service
- organization key administrator
- provider security or support workflow
- backup and disaster-recovery service
- lawful-access or incident-response process
Avoid the vague question "Who has the key?" A hardware module may hold the material while several identities have permission to use it.
3. Separate Possession From Authority
Key material may never leave a managed HSM, yet an authorized service can submit a decrypt operation. Conversely, a customer may own the key policy while granting the provider's service agent ongoing use.
Ask who possesses key material, who sets policy, who grants service access, and who can approve or audit each operation.
4. Test Revocation
For a customer-managed-key claim, verify what happens when access is disabled:
- Does new processing stop?
- Does existing stored data become unreadable?
- How long can cached keys remain usable?
- Are backups covered?
- Can restored key copies still decrypt data?
- Do derived indexes or exported records remain?
Revocation is a control, not proof that every plaintext or derivative disappeared.
5. Check Rotation, Recovery, And Destruction
NIST emphasizes cryptoperiods because keeping one key active indefinitely increases exposure. Confirm rotation frequency, old-key handling, compromise response, backup protection, recovery authority, and destruction evidence.
Destroying the only usable key can make ciphertext permanently unrecoverable. That may be desirable for cryptographic erasure, but only if every required copy is covered and availability obligations are understood.
Questions To Ask An AI Vendor
- Is chat content encrypted in transit and at rest?
- Which stored systems, indexes, logs, and backups are covered?
- Are keys provider-managed, customer-managed, externally managed, or client-held?
- Can service workloads decrypt content during normal operation?
- Does customer-managed key support cover prompts, outputs, files, search indexes, and logs?
- Which service identities have encrypt/decrypt permission?
- Are key-use logs available to the customer?
- What is the key rotation and compromise-response policy?
- What happens after key revocation?
- Can the provider recover data from a backup or separate key copy?
- Is any part truly end-to-end encrypted, and how is AI inference performed on it?
- Where must plaintext exist to deliver the feature?
What Encryption Claims Do Not Prove
"Encrypted At Rest" Does Not Mean Provider-Blind
It normally means stored media is encrypted. Authorized services can still decrypt data to serve the user.
"Customer-Managed Key" Does Not Mean The Customer Is The Only Decryptor
The customer may grant a provider service agent permission to use the key. That is still valuable control, but it is not the same as client-held end-to-end keys.
"End-To-End Encrypted History" Does Not Mean Active Prompts Stay Local
An application can keep saved history encrypted while sending the current prompt to a hosted model. Evaluate history storage and active processing separately.
"Key Deleted" Does Not Mean Every Derived Copy Is Gone
Plaintext exports, logs, indexes, screenshots, model outputs, and separately encrypted backups may follow different controls.
"We Cannot See Your Data" Needs Architectural Evidence
Look for a design explanation: where encryption occurs, who owns keys, where inference runs, how recovery works, and whether the service can authorize decryption. Marketing language alone is not enough.
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, uploads, images, audio, selected local-history context, or AI outputs to train foundation models.
OpenVeil is not fully offline or end-to-end encrypted against every service involved in an active request. Prompts and feature data may be processed by OpenVeil and necessary model, search, upload-processing, hosting, routing, security, billing, and infrastructure providers. Account, billing, security, and operational records are separate from browser-local private-chat history.
The benefit of browser-local history is a narrower normal server-history footprint, not a claim that hosted AI inference occurs without plaintext processing. Read Does Encryption Make An AI Chat Private? for the broader security-versus-privacy distinction.
Frequently Asked Questions
If An AI Chat Is Encrypted, Can The Provider Read It?
Often, yes, when the provider is an authorized endpoint and needs plaintext for model processing. Encryption protects defined states and paths; it does not automatically exclude the service operating the feature.
Are Customer-Managed Keys Better Than Provider-Managed Keys?
They offer more lifecycle control, separation, auditability, and revocation power when implemented correctly. They also create operational responsibility and do not necessarily prevent authorized service processing.
Is A Customer-Managed Key The Same As End-To-End Encryption?
No. A cloud service can use a customer-controlled key through an authorized service identity. End-to-end encryption means intermediaries lack a decryption path to the protected content.
Can Deleting A Key Delete AI Chat Data?
Destroying or disabling the only usable key can render covered ciphertext inaccessible. It does not erase plaintext exports, uncovered logs, derived data, or copies protected by another key.
Why Does Key Rotation Matter?
Rotation limits the amount of data and time exposed if a key is compromised. It also tests whether inventory, access policy, recovery, and dependency mapping are mature.
Can A Hosted AI Be Fully End-To-End Encrypted?
Only if inference is performed in an architecture that does not give the ordinary provider service access to plaintext, such as local execution or a carefully verified protected-compute design. Conventional server-side inference requires access to the prompt during processing.
The Bottom Line
The right question is not simply whether an AI chat is encrypted. Ask which layer is encrypted, who can authorize decryption, where plaintext exists, what the customer can revoke, and which copies sit outside that key boundary.
Provider-managed keys protect infrastructure. Customer-managed and external keys can add control and separation. Client-held end-to-end keys can exclude intermediaries, but they change how hosted AI processing can work. Strong privacy claims should state the exact architecture instead of treating every form of encryption as equivalent.
If you want a paid AI workspace with browser-local private-chat history and no foundation-model training on your prompts, create an OpenVeil account after reviewing the privacy policy and deciding whether hosted processing fits your needs.