Securing AI API Keys in Production

Generative AI keys are worse than database passwords in one way: they are boring to leak. They sit in client code, get pasted into support chats, and end up in public repos through one bad git command. A leaked key does not just expose data, it spends your budget on someone else's prompts.

The first line of defense is architecture: server-side keys only. Browser code should never hold a provider key; route requests through your own backend that attaches the credential. If you must expose something to clients, use scoped, short-lived tokens that can only reach your proxy.

Treat keys like any other secret in the SDLC. Store them in a secret manager, inject them as environment variables, and rotate them on a schedule. When someone leaves the team or a repo goes public, rotation should be a five-minute operation, not a migration.

Rate limits and spend caps are the safety net. Set a per-key cap at a level you can survive, and alert on unusual burst patterns. Most providers now support hard spend caps that stop requests entirely, which is the difference between a surprise bill and a blocked request that you can investigate.

Audit logs complete the picture. Log which key, which model, and which request pattern produced every dollar of spend. When a bill spikes, you want to answer the question: which key, which hour, which model? llm-kita gives you that per-request visibility, with spend caps and audit logs on the dashboard.