Configuring OpenClaw for Encrypted LLM Inference Using TEE Enclaves

OpenClaw Configuration for Private LLM Inference

A developer on r/openclaw detailed their setup for running OpenClaw with encrypted LLM inference using trusted execution environments (TEEs). They switched from standard API-key-based inference to an enclave-based encrypted backend using provider Onera, which runs inference inside AMD SEV-SNP trusted execution environments.

Technical Implementation

The key difference with this approach is that prompts are encrypted end-to-end and sent directly into hardware trusted execution environments. The client performs remote attestation first to verify the enclave identity before sending any data. This means:

• Prompts aren't visible to the host OS
• The infrastructure provider can't read the plaintext
• Inference runs inside hardware-isolated memory

OpenClaw made this integration straightforward since it supports OpenAI-compatible providers. The developer added the provider in ~/.openclaw/openclaw.json and set it as primary.

Configuration Example

Provider configuration:

{
  models: {
    mode: "merge",
    providers: {
      onera: {
        baseUrl: "https://api.onera.chat/v1",
        apiKey: "onr_YOUR_API_KEY_HERE",
        auth: "api-key",
        api: "openai-completions",
        models: [
          {
            id: "openai/gpt-oss-120b",
            name: "GPT OSS 120B (via Onera)",
            reasoning: false,
            input: ["text"],
            cost: {
              input: 0,
              output: 0,
              cacheRead: 0,
              cacheWrite: 0
            },
            contextWindow: 200000,
            maxTokens: 8192
          }
        ]
      }
    }
  }
}

Setting as primary model:

{
  agents: {
    defaults: {
      model: {
        primary: "onera/openai/gpt-oss-120b"
      },
      models: {
        "onera/openai/gpt-oss-120b": {
          alias: "Onera GPT OSS 120B"
        }
      }
    }
  }
}

How It Works

Under the hood:

• Client verifies the enclave via attestation
• Secure channel is established (Noise protocol)
• Prompt is processed inside the enclave
• Response is returned over the same encrypted channel

Tradeoffs Noticed

• Slightly higher latency due to attestation and secure session setup
• More moving parts compared to standard API endpoints
• Stronger guarantees around prompt confidentiality

For working with private repositories, this approach provides a cleaner trust model compared to sending plaintext to typical cloud APIs. The developer mentions other providers exploring similar TEE approaches including Phala and tinfoil AI.