How to run an AI agent on customer data so the hosting provider can't read it

To run an AI agent on customer data so the hosting provider cannot read it, run the agent inside a confidential virtual machine and control where it can send data. Lit sets this up on Google Cloud Confidential VMs, which use Intel TDX to keep the machine's memory encrypted so the host cannot look inside. The agent runs as a Docker container. Its deployment lists the exact hostnames it may reach, a proxy inside the machine enforces that list, and any change to the agent or the list waits for your organization to approve it on-chain. Your team, and any customer you give the evidence to, can check a hardware attestation of exactly what is running.

This is for teams that run agents on data they are responsible for. That includes a company putting an agent to work on its own customers' records, and an AI vendor whose agent runs on a client's data and who needs to show the client what that agent can and cannot do.

Why encrypted memory is not enough for an agent

A confidential virtual machine keeps the host and the cloud operator from reading the agent's memory. That protects customer data while the agent works on it. An agent also makes outbound calls. It calls a model, reads from a database, posts to a ticketing system, and sometimes browses. Every one of those calls carries data out of the machine.

Agents can also be steered by what they read. A prompt injection in a document or a web page can tell the agent to send data somewhere new. If the agent can reach any address, data can leave on the first outbound request. The network list limits that, because the agent can only reach the hosts on it.

Network rules the agent cannot change

With Lit, each deployment declares the hostnames the agent may connect to, like the model provider and the one internal API it needs. Only port 443 is allowed, and wildcards are not. A proxy inside the confidential machine enforces the list, so the agent cannot get around it by changing its own settings, and a prompt injection cannot add a new destination. Every service the agent uses, including a database, has to be reachable over TLS on port 443.

The list is part of the configuration that the hardware measures and records in its attestation. To add a destination, the vendor or your team publishes a new release, and it does not run until your organization approves it. Your organization and the software provider can be required to approve together. Lit, or an independent party, can operate the hardware without gaining control over those rules.

Credentials the agent needs, like an API token for an internal service, are sealed into the confidential runtime when it is deployed. They are not in the agent's code, its image, or its public configuration.

What you and your customers can check

Before sending data to the agent, a customer can check the attestation. It is signed by the Intel processor, and it records the Docker image, the configuration, and the network list. They compare that against the releases recorded on Base for the deployment. The first release is recorded when the deployment is created, and every change after that needs your organization's approval on Base. If the agent was changed without approval, the check fails. Lit gives your team a command that runs this check using only the attestation, the deployment's address, and a public Base RPC endpoint, and you can hand the same evidence to your customers.

Decisions to make with Lit

A few choices shape how private the agent is, and Lit works through them with you.

The first is where the model runs. A model provider on the list sees the prompts the agent sends it. If that is not acceptable for your data, the model runs inside the confidential machine too, on a confidential GPU.

The second is the agent's own behavior. The attestation proves which agent is running, and the agent's code decides what it keeps and what it sends to the services on its list. Review the code and the list together, and Lit can help you read both.

The third is model weights. If the agent downloads weights at startup, they should be checked against the version you expect, and the host they come from goes on the list.

Working with Lit

Lit sets up each deployment with your team. Send us the agent or the vendor's container, describe the data it will handle, and list the services it needs to reach. We will come back with a hardware plan on Google Cloud, a network list for you to approve, and the approval setup for your organization. Then we deploy it and walk your team through the check. To start, use the Lit AI contact form. If the agent also needs credentials that it should never hold at all, the post on giving an AI agent production credentials covers that part.