Shift Log: Separate API Keys Before the Next Handoff

The shift starts with three projects, two deployment pipelines, and an API charge nobody recognizes. The immediate problem is attribution: which workload made the requests, who owns it, and can its access be stopped without interrupting another project?

The practices worth keeping this year make those questions easy to answer. Give each project its own credentials, keep secrets out of ordinary configuration files, and make replacement a routine operation. These habits matter more as applications, coding agents, and background jobs share access to model APIs.

Give each project and environment its own credentials

Start with a separate key for each project. Where the service supports it, split production, staging, and local development as well. A developer experimenting with prompts should not need the credential used by a production queue.

Separate keys make revocation more precise, but they do not automatically create separate permissions, balances, or rate limits. Check which controls the provider actually enforces. If stronger isolation is required, separate service accounts or workspaces may be necessary.

• Assign every credential a project, an environment, and a responsible owner.
• Record its purpose, storage location, and replacement procedure without recording the secret itself.
• Give temporary experiments an expiry or a scheduled removal date.

Use recognizable names such as invoice-worker-production and search-evaluation-staging. Keep names descriptive enough that the next engineer can identify the workload without opening its source code.

Keep endpoint settings beside secret references

Store deployed credentials in a managed secret store and inject them when the workload starts. For local development, use an approved credential manager or an excluded environment file with restricted access. Commit a sample configuration containing placeholders so setup does not depend on copying a teammate’s secret.

Treat the endpoint, model selection, and credential reference as one configuration unit. That reduces mistakes when several projects use compatible clients against different services. A project testing Gemini 2.5 Flash, for example, should resolve its own configuration instead of inheriting whichever key happens to be exported in a developer’s shell.

Check container build steps, diagnostic output, and CI logs for accidental disclosure. Avoid printing complete environment variables during troubleshooting, and redact authorization headers before request logs leave the process.

Separate spending controls from key names

A credential named development does not impose a development budget. Use project limits and alerts where available, and verify whether a configured threshold merely sends a notification or actually stops requests.

Add application controls where useful: bound concurrency, limit retries, and stop unattended jobs after a defined request or token allowance. A failed request followed by aggressive retries can become both an operational incident and a billing problem.

Track usage by project and environment. If provider reporting lacks that detail, attach an internal project identifier to your own usage records without storing credentials or unnecessary prompt content.

Rehearse replacement before a key is exposed

Keep a short replacement procedure with the deployment notes. When overlapping credentials are supported, create a replacement, update the secret reference, deploy, verify requests, and then revoke the old key. Check scheduled tasks and infrequently used workers before declaring the change complete.

Suspected exposure needs faster containment. Revoke the affected credential promptly, assess dependent workloads, and restore access with a fresh secret. Removing a leaked key from the latest commit does not remove copies from repository history, logs, or caches.

Use a shared relay without losing project ownership

Relay365 is worth considering when separate projects need access to multiple model families through a pay-as-you-go relay. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. Its API base is https://api.api365relay.com; OpenAI clients add /v1.

A common connection point can simplify setup, while project ownership still needs explicit configuration and records. Before consolidating workloads, check the available credential controls, usage reporting, and spending controls against your requirements. Create a Relay365 account to evaluate that fit with a bounded test project.

Leave the next shift an owner, a secret reference, a usage view, and a tested revocation procedure for every active project. Those are the records that turn an unexplained charge into a manageable investigation.