Field Notes

concept

Private AI trust boundaries

“Private AI” is only meaningful when it identifies who can see which data at each stage.

Ask four separate questions:

  1. Who can read a saved conversation or document?
  2. Who can read it while it travels?
  3. Who can read it while the model processes it?
  4. Who can link the request to an identity, account, IP address, payment, device, or later tool action?

Vendors answer question 1 and let customers assume the rest.

The trust ladder

The tiers below run from the least trust a customer must place in the operator to the most, so each step down widens the live plaintext boundary.

flowchart TB
  Local["Local only<br/>prompt and retrieval stay on the device"]
  Onprem["Customer-owned or on-premises<br/>organization runs its own hardware"]
  Tenant["Customer cloud tenant<br/>the cloud provider stays a live boundary"]
  Attested["Attested confidential cloud<br/>the client verifies fresh attestation"]
  Contract["Contractual private cloud<br/>the provider promises no retention"]
  External["Ordinary external cloud<br/>the provider may retain or train"]
  Local --> Onprem --> Tenant --> Attested --> Contract --> External
  classDef strong fill:#dceee8,stroke:#2f6258,color:#173b34
  classDef watch fill:#f8edc9,stroke:#9c7620,color:#4e390d
  classDef weak fill:#f4e7df,stroke:#a45f41,color:#55301f
  class Local,Onprem strong
  class Attested watch
  class External weak

Local only

The model, prompt, history, retrieval index, and document chunks remain on the device. No remote model operator sees the content.

The remaining trust boundary is the endpoint: device compromise, a person with an unlocked device, unsafe backups, plugins, or a local service accidentally exposed to the network.

This is the strongest default for sensitive drafting, reading, and retrieval that a local model can perform. See Local AI.

Customer-owned or on-premises

The organization operates the model in its own hardware and network. This removes the startup from the plaintext path, but the customer must secure administrators, logs, backups, updates, and integrations.

This is often the most credible mode for a law practice, clinic, or research team with technical capacity.

Customer cloud tenant

The organization controls the account, configuration, and ordinary administrators in a cloud tenant. That can be a substantial governance improvement, but it is not equivalent to on-premises control. Without confidential computing, the cloud provider and its privileged infrastructure remain a live plaintext boundary.

Attested confidential cloud

The model must process plaintext, but only inside a hardware-isolated execution environment. Before sending it, the client verifies fresh remote attestation: hardware identity, boot state, software measurement, debug policy, and a workload public key bound to the client’s nonce.

The quote normally proves the platform and measured workload, not an arbitrary model name by itself. The measured application must bind a model hash or manifest to a signed, approved release; the client checks that separate release policy too.

An attestation-gated key broker releases a short-lived request key only to that verified workload. The host, hypervisor, and ordinary operations staff should not have access to plaintext. Private AI routing implements this ladder as a decision procedure: offer local first, offer an attested confidential model on opt-in, and fail closed rather than silently downgrade to ordinary cloud.

This is stronger than a no-logs policy, but it is not zero knowledge or conventional E2EE. It still trusts the endpoint, hardware and firmware vendors, the attestation verifier, the declared code, and the absence of exploitable side channels. That last trust is not merely theoretical: the October 2025 TEE.fail attack physically extracted attestation keys from Intel, AMD, and NVIDIA confidential-computing hardware, which would let an attacker with physical access forge a passing attestation for a compromised machine. Confidential AI computing carries the design and that attack’s specifics.

A precise way to state what a TEE changes, for a reader asking why this differs from trusting a privacy policy: without a TEE, the provider’s live production environment is a plaintext trust boundary that a written policy asks the customer to trust unverified. With attested confidential computing, the customer’s own client checks cryptographic evidence, generated fresh for that request, that the code processing the request matches a specific, disclosed, audited software image running on genuine, unmodified hardware, before the client will even encrypt the request to it. The provider still reads the plaintext to compute the answer; no TEE changes that. What changes is who else could read it, and how the customer knows: ordinary administrators, a compromised load balancer, a debugging tool, or a repurposed server cannot silently substitute for the attested workload without failing the attestation check, where a no-logs policy gives the customer no equivalent way to detect that substitution has happened. The remaining trust moves from “we promise not to look” to “you can verify what is running before you send anything,” which is a narrower and more falsifiable claim, not a claim of secrecy from the provider itself.

Contractual private cloud

The provider promises no training, no retention, and restricted access. The model server sees plaintext while computing. The promise can be valuable, and a strong contract is better than a weak one, but the user cannot cryptographically exclude the provider’s live environment from the trust boundary.

Lumo is an instructive, privacy-improving example of this tier.

Ordinary external cloud

The external provider may retain, train on, or use content according to its contract and settings. It may be the best model for a low-risk task, but it must never be reached silently from a mode labeled local or confidential.

The evidence standard

Open source is useful, and it describes a repository rather than a running server.

A stronger service publishes:

  • signed source and build provenance
  • model-weight hashes and model cards
  • a versioned runtime manifest
  • fresh, nonce-bound attestation evidence
  • expected measurements and allowed patch levels
  • a public append-only release or transparency log
  • a client verifier that checks the evidence
  • a local receipt that records the route and result without recording the prompt

Apple PCC is the high-water-mark reference for release transparency and client attestation. Apple Private Cloud Compute security guide preserves its documentation. Brave’s 2025 Leo pilot is useful, but it says provider-side verification is its first stage and client-side end-to-end verification remains future work. Brave Leo TEE pilot records that limitation.

Tool and connector boundaries

Inference privacy is not the whole product. Web search, file upload, plugins, MCP tools, email, document connectors, voice, OCR, analytics, feedback, and support can each create a new plaintext exit.

For each one, disclose:

  • destination and jurisdiction
  • data classes released
  • retention and training terms
  • whether it is inside the attested boundary
  • whether the user must approve it
  • what audit record remains

A private agent should default to no external tools, least privilege, and human confirmation before consequential actions.

Customer-facing language

Good:

Local mode: your prompt and local documents do not leave this device.

Confidential mode: the app verifies an approved, hardware-isolated release before encrypting your request to it.

This reduces the need to trust our infrastructure staff with plaintext. It does not protect an unlocked device, hardware flaws, traffic metadata, or facts you choose to disclose.

Avoid:

  • “zero-knowledge AI” without a named protocol and claim
  • “we cannot access anything” for ordinary cloud inference
  • “multi-provider” as shorthand for confidentiality
  • “anonymous” where a subscription, cookie, support case, timing, or payment can create a link

Built on 6 sources (6 external).

Working out connections…