Customer-Managed Encryption Keys for AI Avatars: An Architecture Guide

Encryption is only meaningful when an organisation can say who controls each key, which workload may use it and what happens when access is revoked. For a private AI avatar, “encrypted in transit and at rest” is not an architecture. Banks, governments and regulated enterprises need a component-level key plan covering live media, stored conversations, knowledge, model artefacts, service identities, backups and software updates.

Customer-managed encryption keys can increase control, but they also introduce operational responsibility. A badly planned rotation can stop speech, retrieval or streaming; a lost key can make records unrecoverable; and a key stored beside the data it protects may provide less separation than the procurement label suggests.

This guide provides a practical design: four custody models, seven cryptographic boundaries, a key-control register, a lifecycle runbook and acceptance tests for public cloud, private cloud and customer-hosted avatar deployments.

Start with control, not the word “encrypted”

An avatar conversation passes through several states. Audio is captured and streamed. Speech becomes text. The system may retrieve permissioned knowledge, call a language model, generate speech, animate a licensed identity and retain selected operational evidence. Each stage has different confidentiality, integrity and availability needs.

Encryption can protect data when storage media is copied or network traffic is intercepted. It does not automatically stop an authorised service, compromised administrator or vulnerable application from reading data after it has been decrypted. Microsoft’s current Azure encryption guidance, updated in July 2026, makes the same distinction: encryption at rest works alongside identity and access controls and does not mitigate compromised credentials or application vulnerabilities.

Ask five questions for every protected asset:

1. What data or operation is this key protecting?
2. Who creates, stores, rotates, disables and destroys the key?
3. Which human and workload identities can request cryptographic operations?
4. Where can plaintext exist during processing, debugging and recovery?
5. What stops working when the key or key-management service is unavailable?

Yepic’s AI avatar data-residency framework can supply the asset and processing map. The key plan adds custody, cryptographic purpose and failure behaviour to every row.

Choose among four key-custody models

Terms such as BYOK, customer-managed keys and hold-your-own-key are not used consistently. Record the actual control rather than accepting the label.

1. Service-managed keys

The cloud or application provider generates, protects and rotates keys. This normally provides the lowest operating burden and can be appropriate for lower-risk workloads or services where provider controls satisfy policy. The customer may receive assurance evidence but cannot independently revoke the provider’s cryptographic access.

2. Customer-managed keys in a provider KMS

The customer controls a key and its policy through a cloud key-management service, while the hosted workload receives permission to use it. Envelope encryption commonly uses that key-encryption key to protect shorter-lived data-encryption keys. The customer can normally rotate, disable and audit use, but the service must still be able to request decryption for approved processing.

This model can deliver useful separation without customer-operated hardware. It also creates a dependency on the provider identity, KMS availability, regional support and the exact resources covered. “CMK enabled” on one database says nothing about transcripts in logs, snapshots, search indexes or object storage.

3. Externally held or customer-operated keys

The root key remains in customer-controlled infrastructure or hardware, and an external key service authorises cryptographic operations. This can meet a stricter custody requirement, but support varies by platform. Network delay, external KMS failure and customer error become part of the service availability model.

Current Microsoft guidance describes externally held-key designs as specialised: they add complexity and can affect performance and availability. That is an important general lesson, not a recommendation for one cloud. Stronger custody is valuable only when the organisation can operate it reliably.

4. Local KMS or HSM in a customer-hosted deployment

For an appropriately scoped on-premise avatar, keys and cryptographic services can sit inside the customer environment. The customer may gain direct control of the infrastructure, access policy and recovery process. It also becomes responsible for redundancy, secure administration, backups, certificate trust, monitoring and replacement of failed hardware.

On-premise does not prove that every key is customer-controlled. A local component may still rely on a supplier licence key, remote certificate authority or embedded secret. Conversely, a well-designed private-cloud service may give the customer stronger and more observable key control than a poorly operated local vault.

Map seven cryptographic boundaries

1. Browser, kiosk and live media

Protect signalling, API traffic and real-time audio and video separately. WebRTC media uses session-specific cryptography: the IETF WebRTC security architecture requires media channels to use SRTP with DTLS-SRTP for keying and data channels to use DTLS. That secures the transport path, but it does not make media opaque to the endpoints that must capture, render or relay it.

Document where encryption terminates, whether a TURN relay can see plaintext, how certificates are validated behind enterprise inspection and whether a recording service receives a decrypted copy. Yepic’s enterprise WebRTC guide explains why firewall, proxy and relay design must be tested in the real customer network.

2. Service-to-service connections

Speech recognition, orchestration, retrieval, language, voice, rendering and telemetry may be separate services even on the same cluster. Protect calls with authenticated transport and short-lived workload identity. Define who issues certificates, which trust anchors production accepts and how renewal works without internet access.

Do not put a long-lived API key into every container. Yepic’s secure SSO and workload-identity architecture separates the user’s identity from service credentials and delegated tokens.

3. Conversation and operational records

Assign separate protection to raw audio, camera frames, transcripts, model responses, feedback, session metadata and audit events. Use purpose-specific retention and access. A single tenant-wide key may be simple, but it can create a large blast radius and make selective deletion difficult.

Where policy requires cryptographic erasure, prove that destroying a key makes the intended data inaccessible without also destroying unrelated records. Backups, replicas, caches and exports must follow the same design.

4. Knowledge and retrieval stores

Source documents, embeddings, vector indexes, metadata and permission mappings can carry different sensitivities. Encrypting a disk does not preserve document-level authorisation after retrieval. The application still needs identity-aware access, and the key policy should not turn a shared retrieval service into a route around source permissions.

Use the permission-aware RAG architecture to keep retrieval authorisation and encryption controls complementary.

5. Models, voices and avatar identity assets

Model weights, voice models, likeness assets, prompts and policy bundles may require confidentiality, but integrity and usage rights are just as important. Encrypt sensitive artefacts at rest, verify their provenance and signatures before loading, and restrict the service identities that can read them. Do not imply that encryption creates a right to use a person’s likeness or voice.

6. Secrets and administrative credentials

Encryption keys are not the same as passwords, API tokens, OAuth client secrets, licence credentials or signing keys. Keep an inventory for each type, use a secrets manager where appropriate, avoid placing secret material in images or logs and rotate it through a tested process. A compromised application secret may let an attacker legitimately request decryption even when the encryption algorithm remains sound.

7. Backups, releases and trust roots

Backup keys need protection and recovery testing equal to the primary keys. Release-signing keys and certificate-authority roots need stricter separation because compromise can authorise malicious software or identities across the environment. The model-update and rollback framework shows how hashes, signatures and known-good bundles belong in the release process.

Build a key-control register

Create one record per key or managed key family. At minimum, capture:

• protected asset, environment, data classification and business owner;
• key type, cryptographic purpose and approved algorithm policy;
• custodian, KMS or HSM location and administrative boundary;
• authorised human roles and workload identities;
• creation method, activation date, rotation trigger and cryptoperiod;
• backup, escrow or recovery method, where policy permits it;
• logging destination and alerts for abnormal use;
• dependencies, cached-key behaviour and outage impact;
• revocation, deletion and evidence requirements; and
• last recovery, rotation and compromise test.

NIST SP 800-57 Part 1 Revision 5 remains the final NIST key-management recommendation while Revision 6 is still a draft. It treats generation, distribution, storage, use, backup, recovery, revocation and destruction as one lifecycle. Apply that discipline to the complete avatar system, not only its database.

Design rotation and revocation as production events

A key rotation is not complete when a new key exists. The workloads must receive permission, new data must use the new version, old data must remain readable for its authorised lifetime and the previous key must be retired without stranding backups or active sessions.

Use a staged runbook:

1. inventory every resource and workload that uses the key;
2. create or activate the successor under dual control;
3. grant the minimum service identities permission to use it;
4. switch new writes or envelopes to the successor;
5. validate live conversations, retrieval, logging and recovery;
6. re-encrypt or retain old data under an approved policy;
7. disable the predecessor for a controlled observation period;
8. revoke or destroy it only after rollback and retention decisions are satisfied; and
9. retain evidence of approvers, timestamps, affected assets and test results.

The NCSC’s guidance on choosing and operating a KMS stresses secure key generation, protected backups, least-privilege access, monitoring and eventual destruction. It also notes the availability consequence: if a key is lost, data protected by it may be unrecoverable.

Test twelve failure and control cases

Before production approval, require evidence that the proposed architecture can:

1. identify the key protecting every stored avatar data class;
2. show where live audio and video encryption starts and terminates;
3. deny a workload access to another environment’s or tenant’s key;
4. rotate a data key without dropping an active conversation;
5. rotate a certificate before expiry and reject an untrusted issuer;
6. disable a customer-managed key and demonstrate the exact service impact;
7. restore approved data after a KMS, HSM or site failure;
8. prove that key material and secrets are absent from logs and support bundles;
9. recover a backup without bypassing current access controls;
10. reject an unsigned or tampered model and release bundle;
11. revoke a supplier or administrator while customer workloads continue where designed; and
12. destroy a test key and reconcile every copy, replica, cache and record it governed.

For a restricted network, run these tests with external connectivity removed. The restricted-network deployment guide explains why local certificate services, time, registries, monitoring and update routes must all survive inside the approved boundary.

Use delivery evidence without overstating key custody

Yepic’s Abu Dhabi Aviation and Oracle integration involved development and production environments, API and iframe integration, real-time streaming, captions, microphone behaviour, WebRTC and corporate-network testing, browser remediation, cybersecurity support and ongoing maintenance.

That work demonstrates why encryption cannot be reduced to one database setting: media, browsers, enterprise data, APIs and operations all cross different trust boundaries. It is not presented as proof of a completed customer-hosted key-management deployment.

Take one key question into procurement

Ask every supplier to complete the same key-control register for the proposed public-cloud, private-cloud, sovereign or customer-hosted design. “AES-256” is not an adequate answer. The useful evidence is which data is covered, who can cause decryption, where the keys live, how access is audited, how rotation is tested and what the service does when a key is revoked.

Yepic can scope private and on-premise avatar implementations on customer-controlled infrastructure and GPUs where the selected models, licences, hardware and operating model support it. The exact KMS, HSM, certificate and custody design must be agreed for each implementation; no universal key technology or completed customer-hosted deployment is implied.

The strongest architecture is not automatically the one with the most keys or the most customer-operated hardware. It is the one that gives the organisation enough custody for its threat model while remaining recoverable, observable and operable under real production conditions.