Home/ Part II — Google AI Studio: First Contact/4. Getting Set Up Without Breaking Anything/4.2 API keys vs project credentials (the safe mental model)

4.2 API keys vs project credentials (the safe mental model)

Overview and links for this section of the guide.

On this page

What you need to understand (and why)

AI-assisted projects often start as prototypes, then quietly become real apps. Credentials that are “fine for a prototype” can become dangerous when you scale, share the repo, or ship to users.

This page gives you a safe mental model so you can answer:

  • What’s the difference between an API key and project-based credentials?
  • Which one should I use right now, and why?
  • How do I store credentials so I don’t leak them?
  • How do I design my app so leaks are survivable?
  • How do I keep credentials out of prompts and logs?
  • How do I rotate and revoke without drama?
  • How do I avoid the “it worked locally, fails in prod” auth trap?
  • How do I keep the vibe loop fast without being reckless?
The principle

Assume credentials will leak eventually. Build systems where leaks are low-impact, detectable, and recoverable.

Two credential models: API keys vs project credentials

At a high level, there are two common models:

  • API keys: “a secret string” your app uses to authenticate.
  • Project credentials: identity-based auth tied to a project with explicit permissions (often via service accounts and IAM).

They solve different problems and carry different risk profiles.

A clean mental model

API keys are easy to start with. Project credentials are how you operate safely at scale.

API keys: what they are good for

An API key is usually a single secret string that proves “who you are” (or at least that you’re allowed to call the API). They’re common because they’re simple.

Strengths

  • Fast setup: easy for local experiments and prototypes.
  • Low friction: fewer moving parts.
  • Good for solo work: especially in a dedicated dev/prototype environment.

Risks

  • Leak risk: keys are easy to copy/paste into the wrong place (repo, prompt, log, screenshot).
  • Harder to govern: less granular control than identity-based IAM in many environments.
  • Harder to attribute: “who made this call?” can be less clear if keys are shared.
  • Rotation pain: if you bake keys into builds or configs, rotating becomes disruptive.
API keys should never be in prompts

Prompts are often stored, logged, and shared. Treat prompts as public. Never paste credentials into model conversations.

Project credentials: what they are good for

Project credentials are identity-based. Instead of “one secret string,” you use an identity (user or service account) that has explicit permissions scoped to a project.

Strengths

  • Least privilege: you can grant only what the app needs.
  • Auditability: easier to answer “who/what did this?”
  • Safer for teams: credentials can be managed centrally.
  • Safer for production: better alignment with governance and compliance.

Costs

  • More setup: you may need to configure projects, roles, and identities.
  • More concepts: IAM, service accounts, scopes, environments.
  • More failure modes: misconfigured roles can look like “random” auth failures.
A practical advantage

Project credentials are usually easier to scale safely because you can change permissions without redeploying secrets everywhere.

Threat model: how credentials fail in real life

Credential mistakes are rarely “hackers in hoodies.” They’re usually workflow accidents.

Common leak paths

  • Git commits: keys in source files, config files, or accidentally committed .env.
  • Logs: printing full requests, headers, or environment variables.
  • Prompts: pasting secrets into AI Studio or chat conversations.
  • Tickets/docs: copying request traces into issues or internal docs.
  • Screenshots: sharing terminal output with secrets visible.

What attackers (or accidents) do with leaked creds

  • Run up cost (mass requests).
  • Exfiltrate data if the credential grants access.
  • Use your identity to call other services if permissions are broad.
The blast radius is your design choice

A leaked credential with broad permissions is a disaster. A leaked credential with strict limits and least privilege is an incident you can recover from quickly.

Safe storage patterns (practical)

Here are safe patterns that keep the vibe loop fast and avoid credential leaks.

Local development

  • Store secrets in environment variables (export ... or a local .env file).
  • Ensure .env is ignored by Git.
  • Load env vars at runtime, not at build time (so you can rotate without rebuilding).

CI / automation

  • Use the CI provider’s secret store.
  • Restrict who can read/edit secrets.
  • Never print secrets in CI logs (redaction should be enforced).

Production

  • Prefer identity-based credentials (service accounts/IAM) where possible.
  • Use a secrets manager if you must store secrets.
  • Ensure least privilege and clear audit trails.
A good default for this guide

Start with a dev/prototype credential (key or equivalent) stored in env vars, with strict quotas. Then graduate to project credentials when you move to shared/team/prod contexts.

Rotation and revocation (treat leaks as normal)

Rotation is part of “adult supervision.” Don’t wait for a crisis.

When to rotate

  • Immediately if you suspect exposure (commits, logs, screenshots, prompts).
  • Periodically on a schedule (even if nothing happened).
  • When team membership changes (especially for shared environments).

How to rotate without pain

  • Keep credentials out of code so updating them is a config change, not a code change.
  • Centralize access through a wrapper so credentials aren’t scattered across the codebase.
  • Use environment variables and a single config entrypoint.
The “rotation test”

If rotating a credential requires editing multiple source files, your design is too brittle. Fix the architecture before you ship.

Logging and redaction rules

Logs are one of the most common leak vectors. Establish rules early:

  • Never log raw credentials.
  • Never log full request headers if they may contain secrets.
  • Never log full prompts if they may contain sensitive user data.
  • Prefer structured logs with explicit fields you control.
  • Redact by default: treat redaction as a normal part of logging, not an afterthought.
A dangerous convenience

“Just print the whole request/response to debug” is how secrets leak. Print minimal fields and add a debug mode that still redacts sensitive values.

Common mistakes (and how to avoid them)

Mistake: committing credentials

  • Fix: use env vars + ignore files + pre-commit checks if needed.
  • Recovery: rotate immediately; remove from history if possible; treat as compromised.

Mistake: pasting keys into AI Studio / prompts

  • Fix: treat prompts as public; never include secrets.
  • Recovery: rotate immediately; assume it’s stored somewhere.

Mistake: sharing a single key across a team

  • Fix: use identity-based credentials or per-user keys with attribution.

Mistake: using production credentials locally

  • Fix: separate dev/prod environments; use least privilege; strict quotas for dev.

Mistake: overly broad permissions

  • Fix: reduce scope; grant only what the current feature needs; review permissions like code.
Default stance

If you’re unsure whether something is sensitive, treat it as sensitive and redact it.

How to choose the right one

Use this decision framework:

  • Solo, early prototype: a dev/prototype key can be fine if stored safely and scoped tightly.
  • Shared/team project: prefer project credentials with IAM and auditability.
  • Production: treat identity-based credentials + least privilege + monitoring as the baseline.
  • High-risk features: move to stronger governance earlier (auth/data access, money, deletions).

Whatever you choose, design for rotation and verification.

Checklists you can reuse

Credential storage checklist

  • Credentials are in env vars or a secret store, not code.
  • .env is ignored by Git and never shared.
  • The app fails with a clear error if credentials are missing.
  • Logs redact sensitive fields by default.

Rotation checklist

  • I know how to revoke/rotate the credential.
  • Rotation requires config change, not code changes.
  • There is a smoke test to validate the new credential works.
  • Old credentials are revoked after verifying the new ones.

Boundary checklist

  • Prototype credentials are isolated from production data.
  • Permissions are least-privilege for the current feature.
  • Cost and quota limits are set to prevent runaway usage.
A safe “done” definition

Credentials are “done” when they are safe to store, safe to rotate, and safe to operate—not when they “work once.”

Where to go next