How to use AI on sensitive company data without the vendor seeing it
Run the AI application in confidential hardware on Google Cloud, allow it to reach only the services you approve, and check exactly what is running before you send it anything. Here is how Lit sets that up.
To use AI on sensitive company data without the vendor seeing it, run the vendor's application inside confidential hardware, allow it to reach only the services you approve, and check what is running before you send it anything. Lit sets this up on Google Cloud Confidential VMs, which use Intel TDX to keep the machine's memory encrypted while it works. The application runs as a Docker container. The list of services it can reach is part of the deployment, and any change to the code or that list waits for your organization to approve it on-chain. Before your team connects, a hardware attestation shows exactly which release is running.
This is for two kinds of teams. The first is a company that wants to use an AI product on legal, financial, health, or customer data and cannot accept "trust us" from the vendor. The second is an AI vendor whose customers keep asking whether the vendor can see their data, and who wants to answer with something the customer can check.
The usual options
The first option is to trust the vendor's policy. Many AI vendors promise not to train on your data or keep it. That is a policy, and the vendor can change it. A breach at the vendor would expose the data anyway.
The second is to self-host an open model on your own servers. Nobody outside your company sees the data, but you have to run the GPUs and the application yourself, and you may give up the vendor product your team wanted.
The third is to run the vendor's product in confidential hardware. The vendor's software does the work. The hardware keeps the cloud operator and the host from reading the data while it is in use, and network rules decide where the software can send it. This is what Lit sets up.
How it works
The vendor's application runs as a Docker container in a Confidential VM on Google Cloud. The processor encrypts the machine's memory, so the host operating system and Google's operators cannot read it. For models that need a GPU, Google's A3 machines with NVIDIA H100 GPUs extend confidential computing to the GPU.
Each deployment lists the exact hostnames the container may reach, on port 443 only, with no wildcards. A proxy inside the confidential machine enforces that list. If the list is empty, the application has no network route out at all and only answers requests on its own ports. The list is part of the deployment's measured configuration, so the vendor cannot quietly add a destination. Adding one is a new release, and it does not run until your organization approves it.
Here is a typical example. An enterprise search app runs in the confidential machine with your documents. Its only allowed destination is the model provider's API. Your team searches and gets cited answers. The model API is the only outside service the app can send your data to, and the vendor cannot add another one without your approval.
What you can check
Before your team connects, you can check two things. The attestation is signed by genuine Intel hardware, and the configuration it records, including the Docker image and the network list, matches a release on your deployment's approved list on Base, where anyone can read it. The first release is recorded when the deployment is created, and every change after that needs your organization's approval. Lit gives your team a command that checks all of this using only the attestation, the deployment's address, and a public Base RPC endpoint.
Decisions to make with Lit
A few choices shape how private the setup is, and Lit works through them with you.
The first is where the model runs. If the application calls an outside model API, that provider sees what the application sends it. Many teams accept that, because it is the only outside service the application can reach. If even the model provider should not see the data, the model runs inside the confidential machine too, usually as an open model on a confidential GPU.
The second is what the application keeps and sends. The attestation proves which software is running, so review that software and its network list together. Lit can help you read both.
The third is the model weights. If the application downloads weights at startup, they should be checked against the exact version you expect.
Working with Lit
Lit sets up each deployment with your team. Send us the application or the vendor's container, describe the data it will handle and the services it needs to reach, and tell us your performance goals. 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.