LLM API Key Leaks: Five Exposure Paths and Rotation

This guide helps you find and contain exposed large language model (LLM) API keys before they can be misused. You’ll review five common exposure paths, revoke affected credentials, and replace them in a controlled order while checking that services still work.

What You’ll Need

• Access to the provider account or organization that issued each key, including permission to revoke and create credentials.
• Access to your source repositories, deployment settings, CI/CD systems, logs, and secret manager, as applicable.
• A list of applications and environments that use each key, plus an owner or on-call contact for each service.
• A secure secret manager or equivalent protected configuration store for replacement keys. Do not use this exercise to copy secrets into a document or chat.

Step-by-Step

1. Prepare a key inventory. Record the provider, key identifier or masked prefix, application, environment, owner, creation date if known, and where the key is stored. Do not record the full key in the inventory. Include development, staging, production, personal accounts, and keys used by scheduled jobs. If the provider offers key usage or audit logs, note where to review them.
2. Check five exposure paths. Search for keys in these places, using secret-scanning tools where available. Avoid printing matches to shared logs or terminals that are recorded.
   • Source code and version history: Current files, old commits, branches, forks, and pull-request diffs. Deleting a key from the latest file does not remove it from history or other copies.
   • Client-side applications: Browser JavaScript, mobile app packages, desktop clients, and public demos. A key shipped to a user’s device should be treated as exposed; obfuscation does not make it secret.
   • Build and deployment systems: CI/CD variables, build output, artifacts, container images, deployment manifests, and debug traces. Check whether variables are masked and whether access is limited.
   • Logs and observability tools: Application logs, exception reports, request traces, analytics, support tickets, and screen captures. Look for authorization headers, environment dumps, or full request configuration.
   • People and collaboration channels: Chat, email, shared documents, issue trackers, paste sites, and screenshots. Check access and retention where possible, and assume a key shared beyond its intended audience may be copied.
3. Assess and contain suspected exposure. Treat a real key found in a public repository, client bundle, or broadly accessible channel as compromised. Record the discovery time and affected services, then check provider usage, billing, and audit records for unfamiliar activity. If abuse is ongoing or the key is public, revoke it promptly rather than waiting for a complete investigation. Preserve relevant evidence without reposting the secret.
4. Create a replacement with limited scope. Use the provider’s key-management controls to create a new key for the affected application or environment. Give it only the permissions and model access the service needs, if the provider supports such controls. Store it directly in a secret manager or protected deployment setting. Never put it in source code, a browser, a public build artifact, or a command that may be saved in shell history.
5. Deploy the replacement safely. Update the secret reference in one low-risk environment first, then run a basic request and check application logs for successful authentication without logging the key. Roll through other services and environments, including workers and scheduled tasks. If supported, keep the old key active only for the short overlap needed to verify migration; do not leave both keys active indefinitely.
6. Revoke the old key and verify. Once all known consumers use the replacement, revoke the old credential in the provider console or API. Confirm that the old key no longer authenticates, then monitor errors, usage, and costs. Check for forgotten replicas, such as preview deployments or infrequently run jobs. If you had to revoke immediately, deploy the replacement as soon as possible and investigate resulting authentication failures.
7. Remove the exposure and prevent recurrence. Delete secrets from active files, settings, logs, and shared locations where feasible; restrict or remove access to copies. For repository history, follow the hosting platform’s sensitive-data removal process and coordinate with repository owners, because collaborators and forks may retain copies. Enable secret scanning and push protection if available, add checks to CI, and document the new key owner and storage location without recording the value.

Common Mistakes

• Deleting a key from the latest commit but leaving it usable in history, forks, artifacts, or logs. Removal does not replace revocation.
• Rotating only production while overlooking staging, local development, previews, or scheduled jobs that share the same credential.
• Putting the replacement in a client app or public repository. A secret delivered to an untrusted device is not private.
• Revoking the old key before identifying dependencies when there is no active abuse. This can cause avoidable outages. If exposure is public or suspicious use is underway, prioritize containment.
• Creating one broad key for many unrelated services. Separate keys make targeted rotation and investigation easier.

Tips

• Use a distinct key per application and environment, and assign a named owner and review date.
• Prefer short-lived credentials or workload identity when the provider and deployment platform support them.
• Mask secret values in CI output, avoid verbose environment dumps, and redact authorization headers before sending logs to another system.
• Keep a rotation runbook with the responsible people, service dependencies, verification checks, and provider revocation procedure. Store instructions—not secret values—in team documentation.
• Set usage alerts or limits where available. They can help detect misuse, but they do not replace access controls or prompt revocation.

Troubleshooting

• The replacement key returns an authentication error: Verify that the correct secret reference reached the service, that the key is active, and that the application uses the expected provider account and endpoint. Check permissions without exposing the key in diagnostics.
• Some requests fail after rotation: Search deployment configuration and job schedules for consumers still using the old value. Redeploy or restart processes that load secrets only at startup. Keep any temporary overlap tightly controlled, then revoke the old key.
• The old key still appears to work: Confirm you revoked the correct key, not just a similarly named credential, and check whether the provider has a propagation delay or separate keys in another account. Ask the provider’s support channel if its documented controls do not explain the result.
• A key is in repository history: Revoke it first. Then follow the repository host’s process to remove sensitive data, notify collaborators to refresh affected copies, and scan again. History cleanup cannot guarantee that every clone or fork is erased.
• You cannot tell whether a key was used: Review available provider usage and audit data, noting its coverage and retention limits. If exposure is credible, do not treat missing logs as proof of safety; revoke the key and check billing and services for unexpected activity.

Frequently Asked Questions

Should I rotate a key that was briefly posted publicly?
Yes. Remove the public copy where possible, but revoke and replace the key because it may already have been copied.

Is deleting a secret from Git enough?
No. It may remain in commit history, forks, clones, or build artifacts. Revoke the credential and address those copies separately.

Can I put an LLM API key in browser code?
No. Browser code is visible to users. Send requests through a server-side component that keeps the key in protected configuration.

How often should keys be rotated?
Follow provider and organizational requirements. Also rotate immediately after suspected exposure, staff or access changes that affect custody, or other loss of control. Short-lived credentials can reduce manual rotation needs when supported.

What if the provider does not let me create a second key first?
Plan a brief maintenance window if needed. Prepare the deployment change, create or replace the credential using the provider’s supported flow, update consumers promptly, and verify service recovery before closing the incident.

Related

• Flash Redesign: Five Directions, One Final Release?
• Generative AI and the Strange Artifacts of Human Culture
• Play an Encoded Video: Find the Format Mismatch