2 minute read

Most AI inference today runs on policy and promises: “no training on your data,” “short retention,” and so on. That’s fine for low‑risk use. But as prompts start touching crown‑jewel assets—customer data, legal drafts, proprietary R&D—security teams increasingly want something stronger than policy: proof.

This post sketches a direction I’m exploring. It’s not a product announcement; it’s a map of where the industry can go.

Why ‘confidential’ needs to become ‘verifiable’

Teams keep circling three practical problems:

  1. Runtime opacity. You rarely know what exact runtime and model binary processed your prompt—or who could read it along the way.
  2. Linkability. Even if content is encrypted, metadata can still tie requests back to specific users or accounts.
  3. Auditability. Security wants an immutable, vendor‑neutral record that this model handled that input under these policies—not a slide deck.

The building blocks to address this exist. The work is packaging them into a portable lane any team can adopt across vendors.

A minimal ‘confidential lane’

Think of a narrow, high‑assurance path your sensitive requests can take:

1) Attested execution. Use hardware‑based isolation with remote attestation so clients can verify the measured runtime and model before any plaintext is handled. Only when policy checks pass does a secure session open end‑to‑end with the isolated runtime. See enclave attestation and verifier posture in major clouds (Google Cloud Confidential Space).

2) Unlinkability by default. Send requests through privacy‑preserving relays or one‑time, unlinkable access grants so serving endpoints can’t tie calls back to an identity. Providers see quotas and ciphertext—not who you are. See Oblivious HTTP for unlinkable request relays (RFC 9458) and Vitalik’s note on one‑time access tokens.

3) Verifiable call receipts. Each call returns a compact receipt binding “what ran” to “what was processed” and “under which policy,” signed by the attested runtime. Receipts are easy to verify and easy to store for later audit. No screenshots, no trust fall.

We can’t guarantee in this implementation but it’s a practical posture: only the isolated runtime and the client see plaintext; the request is unlinkable; and you keep a portable, verifiable record.

Why now

What this is not

  • A guarantee that “no system anywhere ever cached anything.” You can’t disprove what you don’t control. You can prove your exact code path didn’t write plaintext, and that only an attested runtime could decrypt the session.
  • A bet that every token needs heavy cryptography. Use stronger guarantees where they matter most; keep the lane narrow and valuable.

Open questions I’m exploring

  • Performance envelopes. Where does the secure lane clearly pay for itself?
  • Side‑channel posture. What developers need to know about timing and I/O patterns.
  • Policy UX. Binding eligibility (e.g., jurisdiction or role) using selective‑disclosure credentials—without oversharing.
  • Interoperability. A neutral receipt format that works across clouds and models so auditors don’t relearn per vendor.

Founder note

This line-of-thinking isn’t about distrusting providers; it’s about giving security and compliance teams a portable proof that survives org charts and roadmap shifts. My bias here: The steady‑state for sensitive inference is trust‑minimized by design—and simple enough that engineers actually turn it on.

If you’re piloting this class of guarantees and want to compare notes, reach out.

[Written with GPT‑5 Thinking]