--- title: "Separate Production and Development AI Credentials" slug: separate-production-and-development-ai-credentials description: "How to separate production and development AI credentials with environment-specific keys, secret storage, and CI/CD safeguards." author: "Yotta Labs" date: 2026-03-17 categories: ["Infrastructure"] canonical: https://www.yottalabs.ai/post/separate-production-and-development-ai-credentials --- # Separate Production and Development AI Credentials ![](https://cdn.sanity.io/images/wy75wyma/production/c3203df8369da596adc4da9c951ee165593596a8-1200x627.png) Teams should separate production AI credentials from local development and testing keys by using distinct credentials for local development, test, staging, and production, storing each credential in an environment-specific secret path, and injecting each key only into the runtime that needs it. Production AI credentials should require explicit review, have documented owners, and never be reused on developer laptops, in notebooks, in automated test jobs, or in broad CI workflows. Credential separation is an environment design pattern. It does not make every mistake impossible, but it reduces the chance that a non-production workflow can reach production model accounts, spend production budget, or use production data paths by accident. For AI teams, this matters because model APIs are often easy to call from scripts, prototypes, batch jobs, agents, and application backends. A single shared key can travel farther than intended. ## Short answer: use one credential path per environment The baseline pattern is simple: every environment gets its own credential path. A practical setup looks like this: - Local development uses a local or sandbox AI key. - Automated tests use a test-only AI key. - Staging uses a staging AI key that mirrors production behavior without reusing production credentials. - Production uses a production-only AI key available only to production workloads. The key idea is that "production access" should not be the default. A developer should be able to run a notebook, unit test, or local app without ever needing a production model credential. If a non-production system needs higher-fidelity testing, promote that workflow through staging rather than copying a production key into a local `.env` file. For Yotta Labs users, API keys are created and managed in the console under Settings, Access Keys, as described in the [Yotta Labs API keys documentation](https://docs.yottalabs.ai/api-and-sdk/api-keys). Teams should still design their own environment-level credential process around where each key is stored, who can access it, and which runtime receives it. ## Map local, test, staging, and production to separate AI keys and scopes A useful credential model starts with the environments your team actually runs. Most AI teams have at least four classes of activity: local development, automated testing, staging, and production. Each has a different risk profile. - **Local development.** Typical use: Developer iteration, prompt experiments, debugging. Recommended credential pattern: Use a non-production key with limited access to sandbox resources and lower-risk model workflows. - **Test.** Typical use: CI tests, integration tests, regression checks. Recommended credential pattern: Use a test key that supports automation without reaching production accounts or production data paths. - **Staging.** Typical use: Pre-production validation, release candidates, load-like behavior. Recommended credential pattern: Use a staging key that mirrors production configuration where possible, but remains separate from production secrets. - **Production.** Typical use: Live user traffic, production agents, revenue-impacting workloads. Recommended credential pattern: Use a production-only key available only to production services and deployment systems. Where your model provider, gateway, or internal platform supports scopes, use least privilege for each environment. A local key should not be able to call the same set of production models, projects, or accounts as a production service. A CI key should not have broad access simply because it is convenient. A staging key should be close enough to production to validate behavior, but not identical in credential identity. Even when formal scopes are limited, separation still helps. Separate keys let teams revoke a local or test credential without disrupting production. They also make logs easier to interpret because usage from development, staging, and production can be distinguished by credential, account, project, service, or deployment label, depending on the tooling in place. ## Keep production AI keys out of laptops, notebooks, test scripts, and CI jobs Production AI credentials should not be copied into places that are optimized for experimentation. Developer laptops, shared notebooks, local `.env` files, sample scripts, and broad CI jobs tend to be more changeable than production services. They are useful places to build and test, but poor places to distribute production model access. A safer operating model is to separate storage and injection: - Keep AI credentials out of source control, including examples, fixtures, and copied `.env` files. - Store local, test, staging, and production credentials in separate secret locations. - Use CI/CD secret variables for test and deployment workflows, with separate variables per environment. - Inject the key only into the process that needs it at runtime. - Avoid sharing production keys in chat, tickets, notebooks, shell history, or copied configuration snippets. - Make sample code reference placeholder variables, not real production credentials. CI deserves special attention. Many teams start with one CI job and then add linting, tests, previews, migrations, release automation, and scheduled tasks. If the same job has access to a production AI key, non-production steps may inherit production reach. Split CI secrets by job and stage so that test workflows get test credentials, staging deployments get staging credentials, and only production deployment workflows can access production credentials. For notebooks and local tools, use development keys by default. If a production debugging workflow is truly necessary, require a time-bound approval path and remove access after the task is complete. ## Gate production credential access with review, ownership, rotation, and revocation Production credential access should be treated as an operational change, not a casual developer convenience. A useful process defines who can create production keys, who owns them, when they rotate, and how they are revoked. At minimum, production AI credentials should have: - A named owner or owning team. - A clear purpose, such as `prod-chat-service` or `prod-agent-worker`. - A documented storage location. - A list of workloads that receive the key. - A review step before creation, distribution, or permission expansion. - A rotation plan. - A revocation procedure for suspected exposure or service retirement. Rotation and revocation should be designed around blast radius. If a developer key is accidentally exposed, the team should be able to revoke that development key without affecting production. If a test key is overused by a CI loop, it should be possible to disable or rotate it without interrupting live traffic. Production keys should be fewer, better documented, and easier to trace to production services. Avoid treating rotation as only a calendar task. Rotation is also useful when a developer leaves a project, a CI provider changes, a notebook environment is shared more broadly, a key appears in logs, or a service is retired. The goal is to make credential change normal enough that emergency revocation is not a confusing first-time operation. ## Track AI API usage by environment to catch accidental production access Credential separation is stronger when it is paired with usage visibility. If local, test, staging, and production all use separate keys or identities, usage can often be reviewed by environment, service, team, or feature, depending on the logging and billing systems your organization uses. AI API monitoring should answer practical questions: - Which environment generated this model request? - Which service, job, agent, or feature made the call? - Was the request expected for this time of day or release stage? - Did token usage, request volume, or spend change suddenly after a deployment? - Is any non-production system calling a production account or production-only model path? Alerts and reviews should be framed as detection controls. They help teams notice unusual token usage, unexpected production traffic, or cost spikes, but they should not be treated as a substitute for credential separation. Yotta Labs teams that test models in AI Explorer can observe token usage and response speed metrics per query. For broader operational planning, teams can also use environment naming, service labels, deployment metadata, and billing reviews to build a clearer picture of where model usage is coming from. For more on attribution patterns, see Yotta Labs' guide to [tracking token usage by user, team, or feature](https://www.yottalabs.ai/post/track-token-usage-by-user-team-or-feature). ## Use a unified model API surface without creating one shared key A unified model API surface can simplify model access, but it should not become one shared credential across every workflow. This distinction matters for AI teams that use gateways, aggregators, or internal model platforms. [AI Gateway](https://www.yottalabs.ai/ai-gateway) is Yotta Labs' unified API aggregator, bringing models from multiple publishers under one API surface. AI Gateway uses a Yotta API key via the `X-API-KEY` header for Gateway models, so teams do not need to manage separate per-provider credentials for those Gateway model calls. Gateway also handles provider-side authentication and rate limit management. That simplification is useful, but teams should still keep environment-level discipline. A unified API surface should have separate credential handling for local development, test, staging, and production. In practice, that means avoiding patterns like: - One shared Gateway key copied into every developer machine. - One key reused across notebooks, CI, staging, and production. - A production key stored in a generic environment variable used by multiple services. - Test jobs that can call production model accounts because they inherited deployment secrets. Instead, treat the gateway key the same way you would treat any other production credential. Create a clear naming convention, store keys in environment-specific secret paths, inject them only into the correct runtime, and review production credential changes before they go live. ## Credential separation checklist for developers and infrastructure leaders Use this checklist to review whether production and non-production AI credentials are properly separated. - Create separate AI credentials for local development, test, staging, and production. - Keep production AI keys out of laptops, notebooks, shared `.env` files, sample scripts, and general CI jobs. - Use non-production keys by default for developer iteration and automated testing. - Restrict each credential to the narrowest practical use case, where your tooling supports scopes or access limits. - Store secrets outside source control and inject them only at runtime. - Split CI/CD secrets by workflow so tests, staging deployments, and production deployments do not share the same key. - Require review before creating, rotating, distributing, or expanding production credential access. - Assign each production key a documented owner and purpose. - Maintain rotation and revocation procedures for every environment. - Make local and test keys easy to revoke without interrupting production services. - Label or log AI API usage by environment, service, team, or feature where possible. - Review unusual token usage, unexpected request volume, and production usage from non-production systems. - Avoid turning a unified model API key into one credential shared across all workflows. - Document what to do if a key is exposed, including who can revoke it and which workloads must be restarted. For infrastructure leaders, the most important review question is not "Do we have a key?" It is "Can this key only be used in the environment where it belongs?" If the answer is unclear, separate the credential path before the workflow reaches production. ## FAQ #### How should teams separate production AI credentials from local development and testing keys? Teams should create distinct AI credentials for local development, test, staging, and production. Store each key in an environment-specific secret location, inject it only into the runtime that needs it, and keep production credentials out of local machines, notebooks, test scripts, and broad CI workflows. Production access should require explicit review and have a documented owner. #### What key-management setup prevents developers from using production model credentials locally? Use separate service identities or API keys per environment, then keep production keys out of local configuration paths. Developers should receive development or sandbox credentials by default. Production credentials should only be available to production deployment and runtime systems, with a reviewed process for exceptional access. #### How can companies isolate AI API access across development, staging, and production? Companies can isolate AI API access by using environment-specific credentials, separate secret stores or CI/CD variables, least-privilege scopes where available, and clear promotion gates before production access. They should also log or label usage by environment so accidental production calls from non-production systems are easier to investigate. #### What practices reduce the risk of non-production systems reaching production AI accounts? The most useful practices are avoiding shared production keys, separating accounts or projects where possible, blocking production secrets from local and test workflows, reviewing production credential changes, rotating keys, and monitoring usage for unexpected production traffic. These practices reduce operational risk, but they should be combined with normal incident response and access-review processes. #### Should staging use the same AI credential as production? Staging should usually have its own credential. It can mirror production behavior, model choices, and configuration patterns, but it should not reuse the production secret. A separate staging key lets teams test releases realistically while preserving the ability to revoke or rotate staging access without affecting production. #### How does this apply when using AI Gateway? When using AI Gateway, teams can access models from multiple publishers through one API surface, but they should still maintain separate credentials for local, test, staging, and production workflows. The unified API surface simplifies model access, while environment-specific credential handling keeps production access from becoming a shared default across every workflow.