Encryption for AI systems in transit, at rest and in use

Why this matters

You already know the three states of data and the controls for each. What changes with an AI system is the inventory. A conventional application has a database and some traffic. A RAG app over HR documents has the documents, a chunked copy of them, an embedding of every chunk in a vector store, a prompt that pastes retrieved chunks next to the user's question, a response that may quote them, a prompt log that keeps all of it, and a model whose weights may themselves be the most valuable file the organisation owns. Each of those is a separate copy of sensitive data, and each sits in one of the three states at any moment.

Teams encrypt the obvious copies — the source database, the public endpoint — and miss the derived ones, because nobody thinks of an embedding or a debug log as "the data". They are. An attacker who reaches the vector store or the prompt log has reached the HR documents by another door.

The third state is also where AI differs most. Inference needs the prompt, the retrieved context and the weights in plaintext in memory, often on a GPU, often on a machine somebody else runs. Encryption in use is the only control that speaks to that, and it is also the most oversold.

On the exam, encryption scenarios rarely test algorithm choice. They test whether you can identify which state the exposure is in, which copy is unprotected, and who holds the key.

The lesson

Encrypting prompts and responses in transit, including between internal services

The client-to-endpoint hop is usually fine: a hosted model API or your own gateway sits behind TLS, and hosted APIs generally accept only TLS connections. The gaps are the hops behind it.

Trace one request through the toy RAG app from lesson 2. The user's question goes to the application. The application calls an embedding service, then the vector store, then pastes the top chunks into a prompt and sends that to the model runner, perhaps through the local gateway. The response comes back the same way and is written to a prompt log. That is five or six internal hops, and every one carries sensitive content: the question, the retrieved documents, the answer. Internal traffic is where plaintext survives, usually because "it is all inside the cluster" or because the model runner listens on plain HTTP on a local port by default.

The controls you already know apply, aimed at the right places:

• TLS on every hop, including application to vector store, application to model server and gateway to model. A service mesh with mutual TLS is the usual way to get this without changing every client, and it adds service identity, so the model server can refuse callers other than the gateway.
• Streaming responses are still in transit. Token-by-token streaming over server-sent events or WebSockets needs the same protection as a single response; a proxy that terminates TLS to inspect the stream and re-originates it in plaintext reintroduces the gap.
• Tool and agent calls are transit too. When an agent with ticket and email tools calls those systems, or an MCP client talks to an MCP server, prompt content and tool results cross that link. Remote MCP servers should be reached over TLS with authentication; a local server over standard input and output stays on the host, which is a different trust question.
• Training and replication traffic. Moving a dataset to a training cluster, or weights from a registry to inference nodes, is bulk transit of the most sensitive files in the system, and it often runs over storage protocols nobody thought to check.

A point worth holding for scenarios: TLS that terminates at a gateway means the gateway sees plaintext. That is often the intent — it is where the prompt firewall from lesson 10 inspects content — but it makes the gateway a place where prompts exist in clear, so its logs and memory are in scope for the rest of this lesson.

Encrypting training data, model weights, vector stores and logs at rest

List the stores, because the list is the control.

Training and fine-tuning data. Often copied into object storage buckets, notebooks and scratch volumes during preparation, and the copies outlive the project. Encrypt the buckets with keys you manage, and treat scratch and export locations as part of the dataset.

Model weights and checkpoints. A fine-tuned model is intellectual property and, if it was trained on sensitive data, may reproduce some of it. Weights sit in model registries, artefact stores, container images and every intermediate checkpoint saved during training. Encrypt the registry, restrict decryption to the serving identity, and do not forget the checkpoints, which are complete models under a less interesting name. Lesson 19 covers model theft; encryption at rest is one of its controls, though it does nothing against extraction through the API.

Vector stores and embeddings. The copy most often missed. An embedding is not a hash; research has shown that text can be partially reconstructed from its embedding, and most vector stores keep the original chunk text alongside the vector anyway, so the store holds the documents in readable form. Encrypt it as you would the source repository, using the same classification (lesson 14), and check that backups and snapshots inherit the encryption.

Prompt and response logs. Lesson 2's lab logged every prompt deliberately so you could see what the model received. In production that log contains everything users typed and everything retrieval pulled in. Encrypt it at rest, then go further, as lesson 15 describes, because encryption at rest does not stop an authorised reader of the log platform from reading it.

Caches and conversation history. Semantic caches, session memory and agent scratchpads hold prompts and responses for reuse. They are frequently in-memory stores with persistence switched on and encryption switched off.

The design principle: encryption at rest protects against loss of the medium and against access that bypasses the application — a stolen disk, a leaked snapshot, a misconfigured bucket. It does not protect against anyone who can call the application, the vector store's query API or the log search, because those decrypt for them. When a scenario describes data leaking through a legitimate query path, encryption at rest is the distractor; access control and data safety controls are the answer.

Protecting data in use, and what confidential computing does and does not offer

During inference the prompt, the retrieved context, the intermediate state and the weights are all in plaintext in CPU or GPU memory. Whoever controls the host — an administrator, a hypervisor, a compromised kernel, the cloud provider — can in principle read them.

Confidential computing addresses that with a hardware trusted execution environment (TEE): memory is encrypted by the processor with keys the host software cannot read, so the host operating system, hypervisor and provider staff see ciphertext. Its partner is remote attestation: before you send data, the environment proves, with a signed hardware measurement, what code is running inside it. A key management service can be configured to release the decryption key for the weights or the dataset only to an environment whose attestation matches an approved measurement. That combination — encrypted memory plus key release bound to attestation — is the useful pattern, and some recent data-centre GPUs now offer a confidential mode so that model work is not limited to the CPU.

What it does not offer, and this is where scenarios set traps:

• It does not protect against the model. A prompt injection, a jailbreak or a response that discloses training data happens inside the enclave, by the code you attested. Confidential computing protects data from the host, not from the application.
• It does not protect against legitimate callers. Anyone authorised to query the model still gets answers; model inversion and membership inference work through the API regardless.
• It does not cover data once it leaves. The response is decrypted for the user, logged and cached outside the enclave unless you design otherwise.
• It shifts trust rather than removing it, to the hardware vendor and the attestation chain, and it has had side-channel weaknesses over its history.
• It has a cost in performance, availability of hardware and operational complexity.

Two other in-use techniques appear in discussion. Homomorphic encryption computes on ciphertext without decrypting; it is real, but far too slow for large-model inference today and is used for narrow computations. Secure multi-party computation and federated learning keep raw data with its owner during training; federated learning shares model updates rather than data, which reduces exposure but does not eliminate it, since updates can leak information about the data behind them.

Key ownership when the model is hosted by someone else

With a hosted model, the provider's infrastructure decrypts your prompt to run it. The questions are who holds the keys for everything around that moment, and what the provider retains.

The spectrum you know from cloud applies:

• Provider-managed keys. Encryption at rest is on, but the provider can decrypt at will. Protects against stolen media only.
• Customer-managed keys in the provider's key management service. You control rotation, access policy and revocation, and every use of the key is logged in your account. Revoking or disabling the key makes the data unreadable, which is your kill switch for fine-tuning data, stored conversations and vector indexes the provider hosts for you.
• Externally held keys (hold your own key), where the key lives in your own hardware security module or key service and the provider must call out for each use. Strongest separation, highest operational burden, and any outage of your key service is an outage of the AI application.

For a hosted model, ask four things, and a scenario's correct answer usually sits in one of them:

1. What is retained? Prompts, responses, files and fine-tuning data may be stored for abuse monitoring or debugging. Retention you have not negotiated is a copy you do not control, whoever's key encrypts it.
2. Can the stored artefacts use my key? Fine-tuned models, uploaded files, managed vector stores and conversation threads are the things to check.
3. Where are the keys and the processing? Region matters for data sovereignty (lesson 33), and a key held in one jurisdiction does not move the processing.
4. Is prompt content used for training? That is a contractual and settings question, not an encryption one, but it decides whether your data ends up in weights you can never revoke.

Separation of duties carries over from conventional key management: the people who administer the AI platform should not also administer the keys that protect its data.

Reading an encryption requirement in a scenario and choosing the state it applies to

Most encryption questions reduce to one move: find the copy and the state, then pick the control that matches.

• "Traffic between the application and the self-hosted model server is visible to anyone on the cluster network" — in transit, internal hop; mutual TLS.
• "A backup of the vector database was found in a public bucket" — at rest, derived copy; encryption with customer-managed keys, plus the access failure that exposed the bucket.
• "A regulated workload must run on a public cloud GPU, and the provider's administrators must not be able to read the patient data" — in use; confidential computing with attestation-gated key release.
• "The organisation must be able to render all data held by the AI vendor unreadable at contract end" — key ownership; customer-managed keys and a negotiated retention limit.
• "Users obtained other users' records by asking the chatbot" — not an encryption problem. The data was decrypted for an authorised path. The answer is access control at retrieval (lesson 11) or data minimisation (lesson 14).

That last pattern is the most common trap. Encryption is examined as much by recognising when it is irrelevant as by choosing it.