An AI assistant can answer a question with text, but doing useful work often requires a computer. Filling out a PDF, building a spreadsheet, editing an image, or turning a pile of notes into a presentation all require tools, files, and somewhere to run code.

The usual solution is to give the model a sandbox on the AI company’s infrastructure. Your attachments are copied into it, the model’s commands run inside it, and the files it creates are copied back out. The sandbox may protect the rest of the service from the model, but it does not protect you from the service. The company operating the machine has full access to everything in it.

We don’t want Confer to work that way. Our private inference and encryption would not mean much if the model had to send your files and commands into an ordinary server whenever it needed to do something useful with them.

That’s why we built confidential workers: private computers for the model to use that nobody else, including us, can access.

What a worker can do

A confidential worker is a small Linux VM with an ordinary shell and a temporary workspace. It runs inside a Trusted Execution Environment (TEE) with encrypted memory, so the machine hosting it, and anyone operating that machine, cannot read what is inside. The model can write and run programs, copy an attachment into the workspace, inspect or modify it, and return a completed file to the conversation.

The confidential worker image includes Python, PDF utilities, document libraries, and fonts. That is enough to do things like:

  • Fill out or edit a PDF;
  • Create a resume, report, or letter;
  • Build a spreadsheet with formulas and charts;
  • Produce a presentation;
  • Transform images and other attachments;
  • Analyze a dataset or run a calculation; and
  • Generate almost any other file that can be made with code.

The experience is intentionally unremarkable. You ask Confer to fill out a lease, it edits the attached PDF, and a completed PDF appears in the conversation. Underneath, the model used a real computer.

Verifying the computer before using it

Your device never connects to a worker directly. The inference proxy does – the same attested TEE your device already verified before sending it your first message. As with private inference, an encrypted connection is only useful if the machine at the other end is actually confidential, so the proxy verifies each worker before sending it anything.

Before connecting, the proxy creates a fresh random challenge and an ephemeral SSH client key. The confidential worker responds with:

  • A hardware-signed attestation quote;
  • Its ephemeral SSH host key;
  • The challenge and client key it received;
  • The signed manifest for its exact software release; and
  • The release’s Sigstore inclusion bundle.

The hardware quote cryptographically binds the challenge and both SSH keys to the running confidential VM. The proxy verifies the quote, verifies that the expected client and server keys are bound into it, verifies the release signature and transparency-log proof, and compares every measured value in the quote with the signed manifest.

Only after all of those checks succeed does SSH begin. The proxy pins the host key from the quote and authenticates with the client key bound into the same quote. No command, attachment, or other user content is sent before verification.

The rules the proxy uses to accept a worker – the release signing identity, and the requirement that every measurement match a signed release – are part of the proxy’s own measured image. When your device verifies the proxy, it is also verifying which workers that proxy will ever talk to.

The worker image is built the same way as the inference image: reproducibly, with Nix and mkosi from a pinned Ubuntu package snapshot, with the entire root filesystem covered by the measurement through dm-verity. Every release is signed and recorded in a public transparency log, searchable by signer.

This makes the privacy boundary testable: the worker proves what it is running, what is running is reproducible from source, and the encrypted channel is bound to that proof.

One computer, one encrypted session

A worker is assigned to a user simply by connecting to it. Each worker accepts exactly one connection for its lifetime. As soon as one is admitted, it closes its listening socket. Other connection attempts cannot get in. The proxy then establishes end-to-end SSH.

The worker has no public IP, no administrative login, and no persistent home directory. Its only route to the internet is to download Python packages from PyPI; every other destination is blocked by the firewall inside the guest and by the network it sits on. Nothing the model runs inside it has a route to the outside world other than PyPI.

When the encrypted session ends, the worker is destroyed.

Files in and out

An attachment reaches a worker the same way it reaches the model: over the attested channel from your device. When the model needs one, the proxy copies it into the worker over the same attested SSH connection that carries commands and their output.

When the model creates a file for you, the proxy retrieves it over that connection, encrypted to you.

Confidential workers give the model a useful computer without giving anyone else access to your data.

Try it out!