Customer-managed keys vs zero operator access

With customer-managed keys, you control the encryption key's policy. You decide who can use it, you rotate it, and you can revoke it. But the provider's service still uses that key to decrypt your data while it works on it, so the provider's systems see plaintext. Zero operator access means the provider's own staff have no technical path to your keys or your data, even with the highest privileges. That usually takes hardware isolation, where the work happens inside an enclave, and attestation, where the enclave proves which code it is running before it gets any keys. Lit Protocol is built the second way. Keys are derived inside an attested enclave, only the code you approve can use them, and you can make a wallet you control the only account the contract accepts rule changes from.

I will go through what each approach protects, where the line between them sits, and the questions that tell you which one a vendor offers.

What customer-managed keys protect

Customer-managed keys (CMK) are a real improvement over provider-managed keys. This includes bring your own key (BYOK) setups, where you import key material you generated yourself. You set the key's access policy and you get an audit log of every call to the key service. You can also cut off access by disabling the key. Once you revoke it and the provider's cached data keys expire, the provider can no longer decrypt your stored data.

The provider still runs the service, though. The provider's code calls the key service, gets the data decrypted, and processes it. An administrator who can change that code, or read the memory of the machines running it, can reach your data while it is in use. The key policy controls which service can use the key, and it has no control over what that service does with your data afterwards.

Hold-your-own-key (HYOK) setups, such as an external key store, go further. The key stays in hardware you run. The provider has to ask your key manager each time it needs the key to unwrap a data key, and you can log and refuse those calls. Your data is still decrypted inside the provider's service to be processed.

What zero operator access adds

Zero operator access is about the time while data is in use. The work runs inside a trusted execution environment, a hardware-isolated machine whose memory the host cannot read. Before the enclave gets any keys, it produces an attestation, a signed statement from the hardware about exactly which code it booted. Keys are only released to an enclave whose code is on an approved list.

With this setup, your data is protected by the list of approved code and by what that code does. You can read both.

How Lit does it

On Lit, the API server runs in an Intel TDX enclave. Its root keys are released by a key service that checks the enclave's attestation against a list of approved code stored in a contract on Base. Changing that list takes a Safe multisig transaction that anyone can see.

The keys you use are derived inside the enclave, and Lit's code never sends them out. A key is used by Lit Actions, JavaScript functions identified by a hash of their code, and only the actions you put in a group with the key can use it. An action you approve can still return the key if its code does that, so review the actions. The group lives on-chain. In ChainSecured mode a wallet you own, such as your own Safe, is the only account the contract accepts changes from, so nobody at Lit can add an action to it alone. Lit's own Safe, which needs 2 of its 4 signers, can still upgrade the contract that stores the groups or approve new code for the enclave, and either change would show up on Base.

You can check most of this from your own laptop. This confirms the code the API reports is on the approved list.

COMPOSE_HASH=0x$(curl -sf https://api.chipotle.litprotocol.com/info \
  | python3 -c 'import json,sys; print(json.load(sys.stdin)["compose_hash"])')
cast call 0x3F91Deaf16FF7C823eE65081d6bAFA1cEea05FfC \
  "allowedComposeHashes(bytes32)(bool)" "$COMPOSE_HASH" --rpc-url https://mainnet.base.org
# true

To confirm the server is actually running that code, you check the hardware quote. Phala's Trust Center report checks it, and the verification guide links to Phala's steps for checking it yourself.

Questions to ask any vendor

Ask the vendor whether their service runs in an enclave and whether you can verify its attestation yourself, without asking them. Ask who can change the code that runs there, and whether those changes are recorded somewhere you can read. Ask whether any employee can deploy new code alone. Ask where your data is decrypted, and whether that place is inside the attested boundary. Zero operator access means you can check these answers yourself.

Lit's own answers have limits worth knowing. New releases and upgrades to the account contract are approved by a Lit Safe that needs 2 of 4 signers, with no timelock today. The list of allowed OS images and key service instances is governed by a Safe that Phala controls. If you need these decisions to sit with your own team, Lit is open source and you can run your own deployment with your own Safe approving releases. To also own the OS image list, you run it on your own TEE hardware with your own key service instead of Phala Cloud.

Working with Lit

Lit works with teams that need zero operator access for their keys and their AI workloads. The post on using AI on sensitive company data applies the same idea to AI applications. To talk about what you need to protect, use the Lit contact form. The on-chain key release is explained at developer.litprotocol.com/architecture/verification/onchain-kms.