Every AI product asks you to trust it with something. A chatbot gets your questions. A coding assistant gets your source. A journal gets the thing you would not say out loud.
Usually that trust is a policy, a paragraph promising your data will not be stored or trained on. Policies are worth something. But a policy is a promise about what a company chooses to do, and promises can be revised, breached, subpoenaed, or quietly ignored by one employee with database access.
There is a different approach, and it is the one Argo is built on: make it so the company cannot read your data, even if it wanted to. Not “will not.” Cannot. That is a claim about architecture, not intent, and unlike a policy, you can check it.
This post explains the machinery: what a secure enclave actually is, how a TEE protects computation, what remote attestation proves, what none of it protects against, and exactly how Argo uses it, including the one place we currently do not.
The problem: encryption stops at the CPU
We already know how to protect data in two of its three states. Data at rest (sitting in a database) is protected by disk and field encryption. Data in transit (moving across a network) is protected by TLS. Both are solved, boring, and effective.
The gap is data in use. To do anything with your words, run a model over them, generate a reflection: a processor has to load them into memory in plaintext. Multiplying encrypted numbers gives you nonsense. At the instant of computation, the data is readable, and anyone with sufficient privilege on that machine can read it: the operating system, the hypervisor, the cloud provider, an administrator, or malware that escalated far enough.
Encryption protects your data everywhere except the one moment the AI actually looks at it.
Confidential computing exists to close that third gap.
What a secure enclave is
A secure enclave is a region of memory that the CPU itself keeps isolated. A Trusted Execution Environment (TEE) is the broader term for a hardware environment that guarantees that isolation. The distinction is mostly vocabulary; the idea is one thing.
The mechanism is a hardware memory encryption engine sitting between the processor and RAM. Memory belonging to the enclave is encrypted with a key generated inside the CPU at boot, a key that never leaves the silicon and that no software, at any privilege level, can read. Data is decrypted only inside the processor package while executing, then re-encrypted before it goes back to RAM.
The consequence is the interesting part. Dump the physical memory of that server and you get ciphertext. Attach a debugger from the host OS and you are blocked. The hypervisor can schedule the enclave, start it, and kill it, but it cannot look inside it. The trust boundary stops being “the company and everyone with root” and becomes “the CPU vendor and the code in the enclave.”
In practice this is implemented by a handful of technologies: Intel TDX and AMD SEV-SNP for confidential virtual machines, and NVIDIA confidential computing on H100-class GPUs, the last of which is what makes this relevant to AI at all. Protecting the CPU is useless if the model runs on a GPU whose memory is wide open, so the encrypted boundary has to extend across the PCIe bus to GPU memory. That capability is recent, and it is the reason private LLM inference became practical in the last couple of years rather than the last ten.
Attestation: the part that makes it more than a promise
Here is the question that separates confidential computing from marketing: how do you know you are talking to a real enclave at all? Anyone can stand up a normal server and claim the workload is protected.
The answer is remote attestation, and it is the single most important concept here.
As an enclave boots, the hardware computes a cryptographic hash, a measurement, of exactly what was loaded: firmware, kernel, and the application code. The CPU then signs that measurement with a private key fused into the chip at manufacture, whose certificate chains back to the vendor. The result is a signed quote.
Before sending anything sensitive, a client asks for that quote and checks three things:
- Is the signature valid and does it chain to a genuine CPU vendor root? This proves real hardware, not an emulator.
- Does the measurement match the code that is supposed to be running? This proves the enclave was not loaded with a modified build that copies prompts to a log file.
- Is the firmware current, with no known-vulnerable versions? This proves it is not a machine left deliberately unpatched.
Only if all three pass does the client establish an encrypted channel whose keys terminate inside the enclave. That last detail matters enormously: the session is encrypted to the enclave, not to the server operating it. The operator relays ciphertext it cannot read.
Attestation turns “trust us” into “verify the hardware, then trust the math.”
What TEEs do not protect against
Any honest account has to include the limits, because a security property you misunderstand is worse than one you do not have.
- You still trust the CPU vendor. The root of trust is a key Intel, AMD, or NVIDIA put in the chip. If that process is compromised, so is everything above it. Confidential computing relocates trust; it does not eliminate it.
- Side channels are real. Enclaves have historically been vulnerable to timing, power, and speculative-execution attacks that infer secrets without reading memory directly. This is an active research area with a steady history of findings and patches.
- Attestation only helps if it is actually checked. A client that requests a quote and skips verification gets no security at all. This is the most common real-world failure, and it is silent.
- The enclave code still has to be trustworthy. Attestation proves which code is running, not that the code is well written. An enclave whose program deliberately logs your prompts is perfectly attestable and completely unsafe.
- Metadata usually leaks. Request timing, sizes, and frequency are visible to whoever runs the machine, even when contents are not.
Confidential computing is a genuine and large improvement over an administrator with database access. It is not magic, and it is not a substitute for encrypting your data at rest with keys the service never holds.
Where Morpheus comes in
Morpheus is a permissionless network for AI inference. We covered it in depth with David Johnston, the man who coined “DApps” in 2013, now its lead technologist, in an earlier conversation.
The structural point is that Morpheus runs no hardware of its own. It is a set of smart contracts on Ethereum and Base that coordinate a marketplace: independent providers supply model inference on their own machines and are paid on-chain. There is no company operating a datacenter that could decide to retain your prompts, because there is no company in the serving path at all, there is a protocol, and a set of providers competing under it.
That decentralization solves a governance problem, not a privacy one. Spreading inference across many independent operators means no single company holds everything, but on its own, it means your prompt is now readable by whichever operator happened to serve it. Decentralization without confidentiality can widen the exposure rather than narrow it.
The two ideas only work together. Decentralization removes the single trusted company; enclaves remove the need to trust the individual operator who replaces it. Morpheus providers running confidential hardware serve requests they cannot themselves read. That combination, an open marketplace where participants are structurally unable to inspect what passes through them, is what attracted us.
From an engineering standpoint it is refreshingly ordinary to consume: an OpenAI-compatible endpoint at api.mor.org, so an existing integration is roughly a base URL, a key, and a model id.
How Argo actually uses this
Argo layers two independent protections, and it is worth being precise about which does what.
First, zero-knowledge encryption at rest. Your entries are encrypted on your device with a key derived there and never sent to us. What lands in our database is ciphertext. This is the stronger of the two guarantees and it does not depend on enclaves, hardware vendors, or any provider behaving well. If our entire database leaked tomorrow, it would leak unreadable blobs.
Second, confidential inference. When you ask for a reflection, the model has to see plaintext. That work (chat, insights, summaries, and daily prompts) runs on Morpheus inside a hardware enclave, so the plaintext exists only inside a boundary the compute provider cannot read.
Live voice calls are the interesting case, because they are the one place the design has to bend. To reference your past entries while you are speaking, something has to decrypt the relevant ones in real time. Our server holds your key in memory only, for the duration of the call, decrypts just the entries needed to answer, and wipes both the key and the decrypted text the moment the call ends. Nothing is written to disk. It is the one moment the architecture asks for more trust than the rest of the app, which is why it is called out explicitly in the consent screen rather than buried.
The asterisk: voice does not run in the enclave today
We recently moved live voice inference off Morpheus and onto a conventional AI provider. The honest reason is latency.
A spoken conversation has a deadline that text does not. If a reply takes four seconds, the conversation is broken, you start talking over it, or you assume it hung up. Our voice pipeline gives the language model roughly a two-second budget to produce its first token, and when the enclave-backed models we had been using could no longer meet that budget, voice calls stopped working entirely.
We had two options: leave a headline privacy claim intact and ship a feature that did not work, or move voice to a faster provider and say so plainly. We chose the second, and updated the privacy policy, the marketing copy, and the in-app consent screen the same week.
We would rather publish an accurate asterisk than an elegant claim that is not true. A privacy promise you have to caveat is worth more than one you have to defend.
What we learned running on it
One practical note for anyone building on decentralized inference, because it cost us real downtime.
Model availability on an open marketplace is volatile in a way that a commercial API is not. Capacity is finite and gets reallocated toward priority models, and when that happens a model id you have been using for months starts returning 503 model_unavailable, not deprecated, not announced, just gone. During a recent incident we swept the full catalogue and found that the large majority of listed models were refusing traffic, including every one from two major families.
The lesson is that on a decentralized network a model id is an operational variable, not a constant. It belongs in configuration, behind a provider switch you can flip without a deploy, with health checks and latency telemetry on every call. We had the first of those and not the others, which is why a provider-side capacity change became a user-visible outage instead of a log line. That is now fixed.
Why this is worth the trouble
All of this is more work than calling a normal API. Enclaves constrain which models you can run and what hardware they run on. Decentralized networks are less predictable than a vendor with an SLA. Zero-knowledge encryption means we cannot do a great many convenient things, because we genuinely cannot read the data.
We think a journal earns that cost. The value of writing honestly depends completely on feeling safe enough to be honest, and that feeling should rest on something sturdier than a promise. Not because anyone at Argo intends to read your entries, but because the architecture should make the question irrelevant.
The goal is not a company you trust with your journal. It is a journal that does not require you to trust a company.
Argo is open source. The encryption, the inference routing, and the voice pipeline described here are all readable. Privacy claims should be checkable, and that includes the asterisks.
Read more
Morpheus, the protocol. Morpheus tech and privacy walkthrough. Our privacy policy, including the third-party processors named in Section 6.