Technical Whitepaper
Private AI Architecture
How Ubimate adds AI assistance without relaxing the end-to-end encryption guarantee — on-device inference, an anonymous relay to frontier cloud models, and confidential inference inside a hardware-attested enclave.
Forward-looking content. This document describes the intended design for Ubimate’s private AI features (Robo, Nemo, and Sanctum). None of these features has been implemented yet, and the architecture described here has not been finalised. Details are subject to change before release.
1. The E2EE Compatibility Problem
AI assistance and end-to-end encryption appear to be in fundamental tension: if a model runs on a remote server, it must be able to read the content it processes — breaking the zero-knowledge guarantee described in the Zero-Knowledge Architecture whitepaper. Ubimate resolves this tension with a tiered set of architecturally distinct layers that never require the sync server to see plaintext: an on-device model (Robo, §2) for private inference within local hardware limits; an anonymous relay to frontier cloud models (Nemo, §3) for freestanding prompts that never touch the workspace; and — on the roadmap — confidential cloud inference inside a hardware-attested enclave (Sanctum, §4) for the one case the first two cannot serve: a frontier-class model reasoning over the user’s actual encrypted content.
1.1 The core incompatibility
To process text, a model needs plaintext. This means:
- An AI feature that sends your document content to a cloud API (OpenAI, Anthropic, Google, etc.) is a privacy break, regardless of the provider’s own privacy policy.
- An AI feature that runs on the sync server is equally a privacy break: the server, which should only ever hold ciphertext, would be decrypting content to feed a model.
- An AI feature that silently transmits selected context to any external service — even “anonymously” — without explicit per-request user consent is a privacy break.
This is why most notes apps that have added AI features have quietly abandoned their previous privacy claims, or have no meaningful privacy claims to begin with. Ubimate’s architecture does not permit either path: the sync server cannot decrypt content even if instructed to, because it does not hold the keys.
1.2 The three tiers at a glance
| Tier | Where inference runs | What it can see | Trust base |
|---|---|---|---|
| Robo (§2) | User’s device, via the OS system model or a local runtime | Decrypted workspace content, in memory only | The user’s own device — nothing else |
| Nemo (§3) | Third-party frontier model, via a Ubimate relay | Only the user’s explicitly typed prompt — never workspace content or identity | Ubimate’s relay operation (operational, not cryptographic) plus the cloud provider |
| Sanctum (§4, roadmap) | Hardware-attested enclave (TEE) in the cloud | Decrypted workspace content, inside enclave memory only | TEE hardware vendor and the published, attested enclave build |
2. Robo — fully on-device inference
Robo is a small-parameter language model (SLM) that runs entirely on the user’s device. It is a capability rather than a single model: Robo is defined by where inference happens, not by which engine performs it, and it supports more than one on-device backend.
2.1 Backends
Recent operating systems ship a small language model as a system service, callable by any local application. On macOS and iOS, Apple’s Foundation Models framework (macOS 26 / iOS 26) exposes an approximately 3-billion-parameter on-device model with structured output and tool calling. On Windows, Phi Silica is exposed through the Windows App SDK’s AI APIs and runs on the NPU of a Copilot+ PC. Where one of these is present, Robo uses it by default: the weights already ship with the operating system, so there is nothing for the user to download, and inference runs in-process or on the NPU rather than through a local server.
Where no system model is available — Linux, older hardware, a Windows PC without a qualifying NPU, or a Mac without Apple silicon — Robo falls back to a user-installed local runtime such as Ollama. The same fallback covers users who deliberately want a larger model, a longer context window, or a specific model of their own choosing. Ubimate will ship the local-runtime path as a free optional companion app separate from the main installation.
Both backends satisfy the same architectural requirement, which is the only property the privacy guarantee depends on: plaintext is passed to a process on the user’s own machine and never crosses the network. Using the system model does place the operating system vendor’s code in the inference path, but that vendor is already trusted by any application running on the machine — it is not an addition to the trust base in the way a remote service would be.
2.2 Properties
| Property | Detail |
|---|---|
| Backends | The OS system model where available (Apple Foundation Models on macOS/iOS, Phi Silica on Copilot+ PCs), otherwise a user-installed local runtime such as Ollama |
| Execution location | User’s device only. System-model weights ship with the operating system; local-runtime weights are downloaded by the runtime itself. |
| Data flow | Ubimate decrypts the document locally (as it does for display), then passes plaintext to the on-device model — through the OS framework in-process, or to the local runtime over localhost. No data leaves the device. |
| Network traffic | Zero: in-process calls or loopback IPC only. The system-model APIs make no network calls, and the Ollama endpoint at http://localhost:11434 is not exposed to any external network. |
| Model specialisation | Where the backend supports it, Robo is specialised with a LoRA adapter trained on Ubimate’s public schema and documentation only; otherwise the schema is supplied in-context. No user data is used for training or adaptation, because no user data ever reaches Ubimate’s infrastructure. |
| Privacy guarantee | Identical to using the editor without AI: plaintext exists on-device in memory while the document is open, and nowhere else |
| Encrypted document requirement | Robo only operates on already-decrypted in-memory state. It never reads raw ciphertext from disk or the sync server. |
Because inference runs locally, Robo is available offline, has no per-query cost, and adds no latency beyond the model’s own inference time.
2.3 Limitations
Stated plainly, on-device inference costs capability, and the two backends fail in different directions:
- Availability is hardware-gated. Apple’s system model requires Apple silicon and a recent OS with Apple Intelligence enabled; Phi Silica requires a Copilot+ PC with a qualifying NPU, still a minority of installed Windows machines. Linux has no equivalent. This is precisely why the local-runtime fallback exists rather than being an afterthought.
- Context windows are small. The current system models work within a few thousand tokens of combined input and output. That is ample for the tasks Robo is aimed at — rewriting a block, extracting structure, screening a prompt — but not for reasoning across a long document or an entire workspace. Those cases are what §4 addresses.
- Vendor guardrails are not ours to tune. Both system models apply their vendor’s own safety filtering, which can decline to process legitimate personal content. Ubimate cannot adjust or disable it. The local-runtime backend has no such filter, which is a further reason to keep it available.
- Adapters are version-pinned. A LoRA adapter is tied to a specific version of the underlying model and must be retrained when the vendor updates it, so schema knowledge supplied in-context remains the portable baseline.
Where a local runtime is used instead, the trade-off is the familiar one: inference needs a capable CPU or GPU, and Robo’s model is selected for the parameter range that runs acceptably on mid-range consumer hardware.
3. Nemo — anonymous relay for cloud LLMs
Nemo is a privacy-preserving proxy for cases where on-device capability is insufficient — general knowledge lookups, research, creative tasks that benefit from a frontier model. The design constraint is that no workspace content and no user identity ever reaches a third-party model provider.
| Property | Detail |
|---|---|
| What is sent to the cloud model | Only the user’s explicitly typed prompt. No document content, no workspace metadata, no user ID, no account linkage is included unless the user deliberately pastes it into the prompt. |
| Anonymisation | Requests are routed through a Ubimate relay node that strips all HTTP headers that could identify the originating device or account (IP, User-Agent, authentication cookies). The cloud provider sees the relay’s IP only. |
| No persistent context | Nemo sessions are stateless. The relay does not log prompts, does not maintain conversation history server-side, and does not associate requests with a user account. |
| Explicit consent per query | Nemo is not an ambient background feature. The user must explicitly open the Nemo panel and type a prompt. There is no automatic document summarisation, no silent context injection, and no background telemetry. |
| What Ubimate’s server handles | Token authentication for billing (optional subscription) and outbound relaying. The server never interprets, logs, or stores prompt content. |
| What the cloud provider receives | An anonymised API call from the relay’s IP, containing only the user-typed prompt. Indistinguishable from any other API consumer using the same relay pool. |
3.1 Robo-assisted prompt screening
Because Robo runs locally, it can screen a Nemo-bound prompt before it leaves the device. When the user submits a Nemo prompt, Robo analyses it for patterns that suggest sensitive workspace content — document titles, database values, named entities that appear in the open workspace, or fragments resembling encrypted field values.
If a potential data-leakage risk is detected, the UI surfaces an inline warning:
⚠ This prompt may contain content from your workspace.
Review it before sending to an external model.
[Edit prompt] [Send anyway]The check is advisory, not a gate. The user can dismiss the warning and proceed if they intentionally want to include context. The goal is to catch accidental paste-and-forget scenarios, not to restrict deliberate choices.
Screening is a short classification task, well within what a system model handles, so on a device that provides one it is available without the user installing anything. Where no on-device backend is present at all, the warning step is skipped and Nemo operates without screening.
3.2 Limitations
Full transparency requires stating these limitations explicitly:
- User-pasted content (partially mitigated): If the user manually copies document text into a Nemo prompt, that content is sent to the cloud model. Robo-assisted prompt screening (see §3.1) attempts to catch this and warn the user before submission, but the warning is advisory — the user can proceed if the inclusion is intentional.
- Cloud provider logging: Nemo routes through a Ubimate relay, but the destination cloud provider (e.g. the API endpoint operator) may log the prompt on their infrastructure. Users should treat Nemo prompts as inputs to a third-party service, not as end-to-end encrypted communications.
- Traffic analysis: A powerful network adversary observing the relay’s outbound traffic could correlate request timing if they also monitor the user’s connection to the relay. This adversary model is out of scope; Nemo’s anonymisation target is the cloud provider and Ubimate’s own server, not a state-level traffic analyser.
- Relay trust is operational, not architectural: Nemo’s “no-logging” property is currently a guarantee enforced by how Ubimate configures and operates the relay — not a cryptographic fact like the sync server’s inability to read content. A compromised or legally compelled relay operator could, in principle, log outbound prompts. This is a deliberate step down from the zero-knowledge core, accepted because the relay only ever handles user-typed prompts (never workspace content or identity). The roadmap closes the gap by running the relay inside the same hardware-attested enclave described in §4, so that “no-logging” becomes verifiable by remote attestation rather than an operational promise.
4. Sanctum — confidential cloud inference
Sanctum is a planned third tier that closes the gap between Robo and Nemo. Robo keeps content fully private but is bounded by the capability of a model small enough to run on local hardware; Nemo delivers frontier-model capability but only for a freestanding prompt the user is willing to expose — by design, it never sees the workspace. Neither lets a frontier-class model reason over the user’s actual encrypted content, which is exactly what requests like “summarise this workspace” or “answer across all my notes” require. Sanctum targets that case using confidential computing: the model runs on a server, but inside a hardware-isolated enclave that neither Ubimate, the cloud host, nor any operator can read into.
| Property | Detail |
|---|---|
| Execution location | A hardware-attested Trusted Execution Environment (TEE) — e.g. Intel TDX / AMD SEV-SNP CPUs or NVIDIA Confidential Computing GPUs (H100 / Blackwell class). The design pattern mirrors Apple’s Private Cloud Compute: a purpose-built enclave whose only job is a single stateless inference. |
| Key release | The workspace content key (or an ephemeral, workspace-scoped session key derived for the request) is sealed to the enclave and released only after remote attestation cryptographically verifies that the enclave is running a specific, publicly published, reproducible build — not arbitrary operator-supplied code. |
| Data flow | Ciphertext is decrypted only inside the enclave’s encrypted memory, for the duration of inference. The host OS, hypervisor, and Ubimate’s own operators cannot read enclave memory. |
| Output handling | The model’s response is re-encrypted to the user’s key inside the enclave before it leaves. Plaintext never exists outside the enclave boundary. |
| Retention | The enclave is stateless. No prompt, retrieved context, or output is logged or persisted; nothing survives the request. |
| Privacy guarantee | Frontier-model capability over real workspace content, with an attestation-backed cryptographic guarantee that no operator can read the content — stronger than Nemo, though weaker than Robo’s zero-hardware-trust local execution. |
What Sanctum enables that Robo and Nemo cannot: frontier-quality retrieval and reasoning over the full encrypted corpus — ask-across-everything, long-document summarisation, semantic search — without any operator, Ubimate included, being able to observe the content. It is the only one of the three tiers that combines frontier capability with content confidentiality.
4.1 What Sanctum trades away
Full transparency requires stating what Sanctum trades away relative to Robo:
- Expanded trust base: Where Robo trusts only the user’s own device, Sanctum’s guarantee also rests on the correctness of the TEE hardware and its attestation chain. This is far stronger than a policy promise, but it is not the trust-nothing-but-your-own-machine property Robo provides.
- Attestation must be verifiable, not asserted: The guarantee is meaningful only if the enclave build is reproducible and its attestation measurements are published, so an independent party can confirm the running code matches audited source. An unverifiable “it runs in an enclave” claim would be worth no more than Nemo’s operational relay promise.
- Enclave side channels: TEEs have a documented history of microarchitectural and speculative-execution vulnerabilities (the SGX class of attacks among them). Confidential computing raises the bar substantially but is not an absolute guarantee against a determined host with physical access.
- Availability and cost: Confidential-GPU inference capacity is scarcer and costlier than commodity inference, which constrains practical model size and pricing.
Sanctum is therefore positioned as opt-in, per-query, and clearly labelled — the same consent model as Nemo — while Robo remains the recommended default for users who accept no trust base beyond their own device. The name is a working placeholder.
5. Why this architecture resolves the tension
| AI scenario | Ubimate’s approach | E2EE preserved? |
|---|---|---|
| AI operates on document content | Robo: local model on decrypted in-memory state. No data leaves device. | Yes — by architecture |
| User queries a cloud LLM | Nemo: user types a freestanding prompt. No document content or identity transmitted. Robo screens the prompt locally before dispatch and warns if workspace content is detected. | Yes — by explicit design constraint |
| Frontier model reasons over real workspace content | Sanctum (roadmap): inference runs inside a hardware-attested enclave. Content is decrypted only in enclave memory, output is re-encrypted to the user’s key, and nothing is logged; attestation proves the running build. | Yes — by hardware attestation; expands the trust base to the TEE vendor |
| Server-side AI summarisation / search | Not offered. The server cannot decrypt content; this feature class is architecturally impossible. | N/A — feature does not exist |
| Automatic context injection | Not implemented. No background AI agent reads or summarises documents without user action. | N/A — feature does not exist |
The E2EE guarantee is not relaxed to accommodate AI features. Instead, AI features are designed around the guarantee: local where the model is small enough (Robo); explicitly opt-in and context-free where a frontier cloud model handles a freestanding prompt (Nemo); and, where a frontier model must reason over real workspace content, inside a hardware-attested enclave that the operator cannot read into (Sanctum). In every case, plaintext is exposed only to code the user can verify — their own device, or an attested build — never to an operator acting on trust alone.
6. Questions & Responsible Disclosure
The cryptographic foundation this design builds on — key derivation, zero-knowledge authentication, per-workspace content keys, and encrypted collaboration — is documented in the Zero-Knowledge Architecture whitepaper.
If you have questions about this document, want to request a deeper technical briefing, or have identified a vulnerability, please reach out:
- Security vulnerabilities: security@ubimate.com (see full disclosure policy)
- Architecture questions: hello@ubimate.com
We welcome scrutiny. A privacy-first product should be able to defend its claims in public.