Why your API keys should never touch the client

Every week, someone pushes an OpenAI API key to a public GitHub repo. Every month, a startup discovers their Anthropic bill spiked because a key was embedded in their mobile app bundle. This is a solved problem — but most AI deployment tools ignore it.

#The problem with client-side keys

When you build a Telegram bot the traditional way, you typically run a server that holds both the Telegram bot token and the AI provider API key. But many tutorials and quick-start guides cut corners: they embed keys in client-side code, store them in local config files, or pass them through environment variables that get bundled into the frontend.

Once a key is on the client, it's compromised. Full stop. Anyone can extract it from the app bundle, intercept it in transit, or find it in browser devtools. The attacker doesn't need your app — they just need the key.

#OpenClaw's architecture

OpenClaw never sends API keys to the client. Not to Telegram, not to the user's device, not anywhere outside the server boundary. The key lives in an encrypted environment variable on the server container, injected at deploy time and never exposed through any API endpoint.

When a message arrives from Telegram, the server decrypts the key in memory, makes the API call to the AI provider, and returns the response. The key exists only in server memory during the request lifecycle.

#Bring your own key, safely

If you use the BYOK option, your key is encrypted at rest using AES-256 and stored in an isolated vault. It's decrypted only when processing a message, in a sandboxed environment with no network egress except to the AI provider's API endpoint.

You can rotate or revoke your key at any time from the dashboard. The old key is immediately purged — no grace period, no cache.

#The takeaway

If your API key can be found by anyone other than the server processing requests, your architecture is wrong. OpenClaw makes the right architecture the default.