If your Gemini API request says “Your API key was reported as leaked,” Google may have detected the credential in a public location and blocked it. Retrying the same key will not restore access. Google’s documented response is to create a replacement key, update your application, and secure the new credential.

Official references: Gemini API troubleshooting and Using Gemini API keys.

Quick recovery

  1. Open Google AI Studio and inspect the status of your API keys.
  2. Create a replacement key for the correct project.
  3. Update the secret in your server, deployment platform, or secret manager.
  4. Deploy and test a small request using the new key.
  5. Disable or delete the exposed key after the replacement is verified.
  6. Review API usage and billing for activity you do not recognize.

Never paste the key into a public issue, screenshot, chat, or support ticket.

Confirm the cause

Read the full error and HTTP status. Google documents a specific message for keys identified as leaked. A generic authentication error may instead indicate a missing environment variable, the wrong project, or a malformed request. Check the key’s status in AI Studio before changing application code.

If Google has blocked the key, changing the prompt or reinstalling the SDK is not the solution. Generate a new credential.

Replace the credential safely

Create a new key in Google AI Studio or the appropriate Google Cloud project. Update every environment that uses it, including local development, staging, production, scheduled jobs, serverless functions, and CI/CD secrets. Restart or redeploy services that read environment variables only at startup.

Test the new key with a minimal request to a supported model. If that test fails, diagnose the new error rather than assuming the original leak remains the cause.

After verification, disable or delete the compromised key. Removing a key from the latest source file is not enough if it remains in earlier commits, forks, logs, or caches. Rotate it first, then clean up exposed content according to your team’s security process.

Restrict the replacement key

Use the narrowest restrictions that fit the application. Google documents restricting a key to the Gemini API and applying suitable application restrictions. Do not embed a production secret in browser or mobile code, where users can extract it; route API requests through a backend instead.

If a key is shared across several Google APIs, verify the intended restrictions before saving them so legitimate services are not accidentally broken. Prefer dedicated keys for separate applications or environments.

Check for unexpected usage

Review API usage, quotas, and billing around the exposure period. If you find suspicious activity or unexpected charges, follow Google’s billing-support process. Share the project and relevant time window, never the secret itself.

If the replacement key also fails, search your deployment settings for an old credential still being used by another service. Inspect secret references without printing the full key in logs.

When this fix will not work

Replacing a leaked key addresses credential compromise, not unrelated invalid parameters, quota exhaustion, unsupported model names, or service incidents. If the new key is active but requests still fail, use the new status code to diagnose the separate issue.

Prevention: keep keys out of source control, use managed secrets, restrict credentials, set billing alerts, and rotate immediately when exposure is suspected.

Official guidance: Google Gemini API troubleshooting.

For broader AI troubleshooting, start with the exact error and the official documentation for the product involved. This article focuses on the specific API or publishing failure described above, rather than general introductory guidance.