Protect Gemini API keys as production credentials.
A Gemini API key can consume project quota and create billing or abuse risk when exposed. Keep it out of browsers, mobile bundles, repositories, logs, and screenshots; restrict it where supported, isolate environments, and prepare a tested rotation and leak-response process before production traffic begins.
Four layers of key protection
Server only
Call Gemini from a trusted backend so users never receive the underlying credential.
Secret storage
Use runtime environment variables locally and a managed secret store in production.
Restrictions
Apply the current Gemini API and application restrictions supported for the credential type.
Rotation
Replace keys without downtime, disable compromised credentials, and audit usage after an incident.
Keep keys out of client applications
A key embedded in JavaScript, a browser extension, desktop bundle, or mobile app can be extracted. Route requests through a backend that authenticates users and enforces application policy.
- Never use a public build-time variable or return the key from an API response.
- Do not rely on minification, obfuscation, or hidden source maps to protect a credential.
- Authorize each user request before the backend calls Gemini.
Store secrets outside source control
Local environment variables are convenient for development; production should use the hosting platform's encrypted secret facility or a managed service such as Google Cloud Secret Manager.
- Ignore local secret files and scan commits and build artifacts for accidental exposure.
- Limit who and which service identities can read the production secret.
- Avoid printing environment variables, request headers, or full configuration during debugging.
Restrict and isolate credentials
Follow Google AI Studio's current guidance for the key type in use. Apply supported API or application restrictions and keep separate credentials for local, staging, and production environments.
- Do not reuse one unrestricted key across unrelated products or Google services.
- Grant only the project access needed to create, manage, or use credentials.
- Test restrictions in staging before applying a production change that could block traffic.
Rotate keys and respond to leaks
Rotation should be a rehearsed deployment process. Create a replacement, deploy and verify it, then disable or delete the old credential according to the current provider workflow.
- For a suspected leak, replace the key immediately and do not wait for confirmed abuse.
- Review quota, billing, logs, repositories, packages, support tickets, and screenshots for the exposure path.
- Document the incident and fix the process that allowed the secret to escape.
Monitor use without logging secrets
Observe traffic and cost at the application and project layers. Useful records include environment, endpoint, authenticated user or tenant, latency, token use, response status, and a safe request identifier.
- Set billing alerts, quota controls, per-user limits, and anomaly notifications.
- Redact authorization values, sensitive prompts, uploaded content, and personal data from logs.
- Investigate unexpected geography, volume, error spikes, and round-the-clock traffic.
Python
This example fails safely when GEMINI_API_KEY is missing and never prints the credential. Keep both key and model configuration in the server runtime.
import os
from google import genai
api_key = os.environ.get("GEMINI_API_KEY")
if not api_key:
raise RuntimeError("GEMINI_API_KEY is not configured")
client = genai.Client(api_key=api_key)
model = os.environ["GEMINI_MODEL"]
response = client.models.generate_content(
model=model,
contents="Return a one-line health-check response.",
)
print(response.text)