Confidential AI for Journaling: Enclaves, Attestation and Limits

End-to-end encryption can protect a journal while it is synchronized and stored. AI creates a separate problem: a model normally needs readable input while it generates an answer.

Confidential AI reduces that exposure by running the model inside a hardware-isolated trusted execution environment (TEE) and verifying that environment before sensitive input is sent.

In DeepJournal, the desktop client also encrypts AI request and response bodies for the enclave. The application proxy routes an opaque encrypted body instead of parsing journal text.

Why encrypted storage is not enough for AI

Imagine an application with excellent E2EE sync. Its server stores only encrypted journal entries. When the user presses “Summarize,” the app decrypts an entry and sends it to a conventional AI API over HTTPS.

HTTPS protects the network connection, but the receiving service still sees plaintext so it can run the model. “We do not train on API data” is a valuable policy, yet it is not a technical barrier preventing infrastructure or administrators from accessing input during processing.

Confidential computing changes where plaintext is allowed to exist.

What is a trusted execution environment?

A TEE is an isolated execution environment supported by hardware. Its purpose is to protect code and data from the surrounding host operating system and infrastructure while a workload runs.

For confidential AI, three properties matter:

• isolated memory: decrypted prompts and model state are intended to remain inside protected memory
• measured software: the environment exposes a cryptographic measurement of what it is running
• remote attestation: a client can verify that measurement before sharing a secret

The important word is verify. Merely hosting a model on hardware that supports enclaves does not prove the expected code is running.

For a vendor-neutral introduction, see Microsoft's overview of trusted execution environments.

DeepJournal's confidential AI request path

The current request flow is:

1. The desktop client selects an allowed model endpoint.
2. The client verifies the enclave identity and expected deployment through attestation.
3. It encrypts the AI request body for the enclave using the Encrypted HTTP Body Protocol (EHBP).
4. DeepJournal's proxy verifies the user's account, budget, rate limits, and requested model.
5. The proxy forwards the encrypted body without treating it as ordinary JSON prompt content.
6. The enclave decrypts the body, runs the model, and encrypts the response body for the client.

This extends encrypted transport beyond a normal TLS termination point: an intermediary can route the request without holding the body-decryption key.

What EHBP encrypts

EHBP encrypts the HTTP body. That is where prompts, retrieved journal passages, and model output are carried.

HTTP headers are not inside that encrypted body. The service can still observe information required to operate the request:

• account authentication
• selected endpoint and model
• request identifiers
• timing and approximate size
• rate-limit and concurrency state
• token usage and billing metadata

Confidential AI should therefore be described as protecting AI content bodies during processing—not as hiding the existence of a request.

Confidential AI versus E2EE

The two protections solve related but different problems.

DeepJournal uses all three. Its sync protection uses end-to-end encryption for entry content and configured memory, thread, and chat fields, while operational metadata remains visible. Read End-to-end encrypted sync for the field and metadata boundaries.

What confidential AI does not guarantee

Confidential computing narrows trust; it does not remove it.

It cannot guarantee:

• that a language model's answer is accurate or appropriate
• protection against malware controlling an unlocked laptop
• privacy after a user copies content into another service
• that headers, request timing, sizes, and usage are invisible
• freedom from flaws in the client, cryptography, attestation verifier, enclave code, model, or hardware
• medical, therapeutic, legal, or financial reliability

The client still trusts the verified enclave measurement and the code represented by it. Hardware isolation also has a security history and must be maintained like any other critical system.

Current models

DeepJournal's current backend allowlist includes Kimi K2.6, GLM 5.2, Gemma 4 31B, and GPT-OSS 120B for analysis. A separately configured confidential model handles embeddings.

Model availability can change. The backend registry—not an old blog announcement—is the source of truth.

Questions to ask any “private AI” product

1. Where is content decrypted?
2. Does the application server receive plaintext?
3. Is inference on device, inside an attested enclave, or on a conventional API?
4. Who verifies attestation, and what software measurement is expected?
5. Which headers and usage metadata remain visible?
6. Is content stored or used for training?
7. Can the user exclude and delete AI context?
8. Does the product document failure modes rather than only benefits?

For a product-by-product comparison of privacy boundaries, long-term memory, platforms, and price, see seven AI journaling apps.

The useful standard

A private AI claim should be testable. It should name the boundary, explain where plaintext exists, disclose metadata, and say what happens when verification fails.

That is why DeepJournal separates its Confidential AI documentation, End-to-end encrypted sync guide, and E2EE guide. Each protection has a specific job.