One key per environment, never in the client

A startup uses the same key on developers’ laptops, in CI and in production; it’s in a .env file committed a year ago. A laptop gets lost and nobody knows what breaks if the key is revoked. Another company put the key inside its mobile app to ship fast: two weeks later usage tripled with the same users, and requests arrive from unknown IPs. Both situations are avoided with three rules.

Rule 1: the key lives on the server

An API key inside a frontend, a mobile app or a desktop binary is public: anyone can extract it. Obfuscating it only slows down whoever is looking for it.

The right design:

• the client talks to your backend, which handles authentication of each user with your session system;
• the backend calls the API with the key, which never leaves the server;
• every request is logged with the user who made it, so you know who consumes what and can set per-user limits.

If the key has already leaked, revoke it first and fix the architecture after. Lowering the spend limit or filtering by user agent doesn’t close the hole.

Rule 2: one key per environment

• Separate development, CI and production. With Console workspaces, each environment has its own keys and its own spend limit. Revoking the development key doesn’t take production down.
• Keep them in a secrets manager: your cloud provider’s or your CI platform’s. Never in the repository, not even a private one, and not in an encrypted .env with a shared password.
• Give each key the minimum scope: one per service or team, not one for everything.
• Out of the model’s context: a key doesn’t go in a prompt, in CLAUDE.md or in the configuration of an MCP server others share. Credentials for external systems stay on the side of the server that runs the tool.

Rule 3: rotate and monitor

• After a leak, the response is immediate: revoke, issue a new key and replace it in the secrets manager. Rotating “every quarter” doesn’t help if the exposed key stays active until then.
• Periodic key rotation is easier when each environment has its own and the code reads it from the manager: you change it in one place and no code changes are needed.
• Access monitoring spots what’s unusual: usage per key and per environment (the Console lets you export usage by key and model), alerts on spikes or unknown IPs, and logs of which user made each request.

Identity and access level

Authenticating tells you who someone is; you also need to verify what they can do. If an agent feature is for supervisors only, the backend checks the session’s role before running it, instead of trusting what the user says in the chat or a parameter the model picks.

The usual traps

• A key in the app bundle or in a frontend build environment variable.
• A single key shared by every environment.
• Renaming the file and adding it to .gitignore without rotating the exposed key.
• Obfuscating the key or restricting by user agent.
• Encrypting the .env inside the repository and sharing the password.
• Lowering the spend limit as the only response to abuse.

On the exam

If the scenario has a key in the client and usage that doesn’t match real users, look for revoking it and routing calls through a backend that authenticates and logs per user. If it has a shared or committed key, look for rotating it now and separating keys per environment in a secrets manager.