Secure API Keys When an LLM Writes Code

When an LLM generates code, it can accidentally put an API key in a source file, a log, or a prompt that gets shared. These steps keep credentials out of generated code, limit the damage if one leaks, and help you review changes before deployment. You’ll need access to the project, its deployment settings, and the service that issued each key.

What You’ll Need

• A code repository and a way to review changes before merging or deploying.
• Access to the API provider’s dashboard so you can create, restrict, and revoke keys.
• A secret store or environment-variable configuration for your development and deployment environments.
• Optional but useful: a secret-scanning tool and a separate test or staging key.

Step-by-Step

1. Decide where the code will run. Identify whether the generated code belongs in a browser, mobile app, server, build pipeline, or local script. Anything shipped to a browser or end user can be inspected, so a secret embedded there cannot be kept private. For client-side features, use a server-side component to hold the key and make narrowly scoped requests on the client’s behalf. Public identifiers designed for browser use are different from secret API keys; follow the provider’s guidance for restricting them.
2. Give the LLM a clear instruction before asking for code. Say: “Do not include credentials, real keys, or secrets in source code, examples, logs, or tests. Read the key from the named environment variable. Use a placeholder in documentation.” Specify the variable name, such as PAYMENT_API_KEY, and the intended runtime. Do not paste a live key into a prompt to help the model configure the code.
3. Ask for a safe configuration pattern. Have the code read the credential from the server’s environment or an approved secret manager. For example, server-side JavaScript can read process.env.SERVICE_API_KEY; Python can read an environment variable through os.environ. Check that missing configuration produces a clear error without printing the key. Avoid putting secrets in command-line arguments, URLs, frontend environment variables, or files that are committed.
4. Configure secrets outside the repository. Store the development key in an approved local secret store or an ignored local environment file. Add the file to .gitignore before creating it, and commit a separate example file containing only variable names and placeholder values. In deployment, add the secret through the platform’s protected configuration or secret manager. Limit who can read or change it, and use different credentials for development, staging, and production.
5. Restrict each key at its source. Create a separate key for each application or environment where the provider supports it. Grant only the required permissions, restrict allowed origins, IPs, products, or endpoints when available, and set usage limits or alerts if offered. Do not treat restrictions as a substitute for keeping a key secret. Confirm that the application still works with the narrower permissions before deploying.
6. Review the generated changes. Inspect the full diff, not just the main function. Search for strings resembling credentials, authorization headers, tokens, URLs with embedded credentials, and accidental debug output. Check configuration files, test fixtures, documentation, build artifacts, and logs. Run secret scanning on the changes and repository history if available; scanners can miss novel formats, so review remains necessary.
7. Test without exposing the value. Use a test credential or a mock service where possible. Verify that the application fails safely when the variable is missing, sends the credential only to the intended service over HTTPS, and does not include it in errors or logs. Make sure the browser bundle and downloadable build do not contain a server-side secret.
8. Merge and deploy through a controlled process. Keep review and secret scanning in the normal pull-request or deployment workflow. Configure production secrets in the deployment environment rather than copying them into generated files. After release, check service usage and application logs for unusual activity, while ensuring logs do not record credential values.
9. Rotate a key if it may have been exposed. Revoke or disable the affected key in the provider dashboard, create a replacement with appropriate restrictions, update the secret store, and redeploy. Check repository history, build artifacts, prompts, logs, and shared tickets for copies. Removing a key from the latest commit does not make an exposed key safe again.

Common Mistakes

• Putting a key in frontend code. Bundling, minifying, or obscuring it does not make it secret. Keep privileged credentials on a server.
• Committing a local environment file. A later deletion does not erase the earlier commit. Ignore the file before adding secrets and scan history if it was committed.
• Trusting a placeholder too much. Generated examples sometimes replace a placeholder with a real value elsewhere, such as in a test or log. Search the entire change.
• Using one unrestricted key everywhere. A leak then affects every environment and may grant more access than the application needs.
• Assuming a private repository or prompt is a vault. Access can spread through collaborators, integrations, backups, or provider settings. Treat live credentials as sensitive wherever they are entered.

Tips

• Use descriptive variable names, but never include the secret itself in the name or in sample output.
• Prefer short-lived credentials or automatic rotation where the provider and application support them.
• Keep a committed .env.example limited to names and obvious placeholders, and document where real values are configured.
• Use a mock or test mode for automated tests rather than granting CI access to production credentials.
• Ask the LLM to explain how the code loads and uses the key, then verify that explanation against the actual diff.

Troubleshooting

The application says the key is missing: Check the exact variable name, environment, and deployment configuration. Restart or redeploy if the platform only loads configuration at startup. Do not fix the issue by hard-coding the key.

The provider rejects the request: Confirm that the key belongs to the expected environment, is active, and has the required permissions. Check endpoint and account settings without printing the credential. If you change the key, update the secret store and redeploy.

A scanner reports a secret: Treat the finding as real until verified otherwise. If it is live or might be live, revoke it first, then remove the value from tracked files and investigate history and artifacts. A scanner’s clean result is not proof that no secret is present.

A key appeared in a prompt, log, or commit: Revoke and replace it even if the content was later deleted. Review access and usage, remove remaining copies where possible, and check whether the provider offers audit information. Do not rely on deletion alone.

Frequently Asked Questions

Can an LLM safely write code that uses API keys?
Yes, if the code reads credentials from runtime configuration and you review the result. Do not provide a live key in the prompt or assume generated code handles it securely.

Is an environment variable always secret?
No. It is a way to supply configuration, not automatic protection. Limit access to the process and deployment settings, and avoid exposing values through logs, diagnostics, or client-side bundles.

Can I put an API key in a private repository?
Do not. Private repositories can be shared, copied, backed up, or accessed by integrations. Keep the secret in a secret store and commit only placeholder configuration.

What should I do if a key was committed?
Revoke it promptly, create a restricted replacement, and update the deployment. Then remove the value from current files and investigate repository history, logs, prompts, and build artifacts.

Are public API keys safe to expose?
Some services provide identifiers intended for client-side use, but they may still need origin, scope, or usage restrictions. Check the provider’s documentation and never expose a credential that grants private or privileged access.

Related

• Vibe Coding: Meaning and Why Games Get Complicated
• Photoshop Font Menu: How to Find and Use It
• LinkedIn Fake Accounts: How to Spot and Report Them