Confer now has folder files! You can add PDFs, Word documents, presentations, spreadsheets, HTML, Markdown, or plain text to a folder, and those files become available to every conversation inside it. Add something once, then ask about it whenever it becomes relevant.

An attachment stays with one conversation. A folder file is there for every conversation you start in that folder.

A folder full of context

Imagine a folder called Health. It might contain lab reports, visit summaries, imaging reports, insurance explanations of benefits, and a medication list. Before seeing a new specialist, you could ask for a single timeline of diagnoses, medications, procedures, and unusual results, with each item linked back to its source. You could ask how a lab value has moved over five years, whether it changed after a medication was introduced, or where a symptom first appeared in your record.

Or imagine a Finances folder with tax returns, bank statements, benefits documents, a lease, and mortgage paperwork. You could ask why your mortgage payment went up, which subscriptions and insurance premiums have quietly increased, or where to find every number your accountant requested. You could trace an unfamiliar merchant across years of statements without opening a few dozen PDFs yourself.

The same idea works for a house (inspection report, contractor quotes, manuals, warranties), or a long-running project (papers, books, specifications, notes, spreadsheets). Rather than repeatedly attaching the same files to unrelated conversations, the folder becomes a persistent body of context that each conversation can draw from.

The feature itself is simple: instead of handing the assistant one document at a time, give it a filing cabinet. The catch is that filing cabinets tend to contain exactly what people are least comfortable giving an AI company – medical histories, bank statements, tax returns, contracts – and a collection of these documents is often more revealing than any one of them.

How document search usually works

An LLM cannot read a PDF or Word document directly. Those files are binary containers full of encoded text, fonts, images, drawing instructions, page geometry, and other machinery. A multi-modal model can process raw text or images, so before it can do anything useful with a document, the file has to be translated into those forms.

Conventional non-private AI services begin by receiving the original file in plaintext and extracting the text embedded in it. Scanned pages require an additional OCR path (which isn’t supported by default for most services), or pages are rendered as images so the model can see things text extraction does not represent well, like tables, charts, forms, handwriting, and spatial layout.

The extracted text is then divided into smaller passages and indexed so that relevant sections can be found later without putting the entire document into the model’s context every time. By the time the document is ready to use, the service has several representations of it: the original file, extracted text, a search index, and – when visual processing is enabled – layout metadata and page images. All of the representations it creates are plaintext.

This makes retrieval easier, but it also gives the company operating the service a readable document library specifically organized to make the information inside it easy to find.

For Confer, we wanted the same useful result with a different privacy boundary. The original is encrypted before it leaves your device. It is decrypted only inside an attested Trusted Execution Environment (TEE), where the model also runs. Text extraction, indexing, retrieval, and inference all happen inside that boundary. The derivatives are encrypted before they leave the TEE, and are only opened there again when a later request needs them.

The document pipeline still works; it just never produces a durable plaintext copy that we can read.

Producing ciphertext from ciphertext

Every folder file is encrypted on your device with a fresh, random 256-bit key before it is uploaded. Object storage receives ciphertext. The filename, key, and references required to use the file are kept in the folder’s encrypted metadata, protected by the same passkey-derived key hierarchy as the rest of Confer.

To prepare the document for search, the client sends its key and opaque storage reference through Confer’s attested encrypted channel into the TEE. The host machine cannot read the channel or inspect the TEE’s memory.

Inside that environment, the document is decrypted and transformed:

  1. Text is extracted, with OCR used selectively for pages that need it.
  2. Page, layout, and visual information is preserved.
  3. The text is divided into searchable passages.
  4. A compact artifact is built with the canonical text, page references, extraction confidence, and an SQLite full-text index.
  5. The canonical text and artifact are encrypted before leaving the TEE.

The resulting storage layout contains the original, the extracted text, and the search artifact – but all three are ciphertext protected by the file’s key. We get a durable search index without getting a document database that we can read.

Asking a question later

When you start a conversation in the folder, your client decrypts the folder manifest locally. The file capabilities required for that request – an opaque object reference and its key – travel to the TEE over the encrypted inference channel.

These capabilities are orchestration state, not model arguments. The model never gets to choose a storage path or request an encryption key. It gets four fairly ordinary tools instead:

  • file_overview describes a document’s structure.
  • file_search searches one file or every file in the folder.
  • file_read retrieves surrounding pages when an exact value, date, or quotation needs context.
  • file_view renders a page when the answer depends on a table, chart, scan, form, handwriting, or spatial layout.

If you ask, “How has my A1C changed over the last three years?” the model can search the Health folder, read the pages surrounding matching lab results, and view a page when a table was not represented reliably in extracted text. Search terms and results are plaintext only inside the TEE. If a rendered page has to make a short trip through object storage, it is encrypted with a fresh key and given short-lived retention.

The model is running inside that same TEE, so retrieved text and rendered pages do not have to cross the privacy boundary to reach it.

This is basically retrieval-augmented generation, except the provider does not have a readable retrieval database.

A TEE is not a database

The useful way to think about a TEE is as a place where sensitive computation happens, not as a permanent home for sensitive data. Confer’s TEE is stateless with respect to documents: during extraction it opens one source, produces encrypted derivatives, and discards the plaintext working state; during a question it opens the encrypted artifact, passes relevant evidence directly to the model running in the same TEE, and discards it again.

All durable document state outside the TEE is ciphertext, and keys arrive inside only when there is work to perform. This is what “stateless” means here: not that the files are forgotten, but that no plaintext document library or search database persists between requests.

Remote attestation makes this boundary verifiable. The client checks the code running inside the TEE against Confer’s reproducible build before sending any requests.

The experience

The result of all this is fairly mundane. Add files to a folder, and then start asking questions.

We think privacy technology is most successful when the result looks like an ordinary feature. Nobody wants an encrypted document extraction pipeline. They want a Health folder that helps them with insights, or a Finances folder that can find the number buried on page 47, without creating yet another company that knows the contents of both.

Try it out!