Skip to content

Integrating AI Platforms: Claude, OpenAI, Gemini and Open Models via API · Platform foundations · lesson 2 of 19 · 13 min

API keys, authentication and secrets management

What you are protecting

An AI API key is a bearer credential: anyone who has it can spend your money and, depending on the platform, access stored files, batches, fine-tunes or organization data. Leaked keys are routinely found in public repositories, mobile app bundles and front-end JavaScript within minutes, and abused for free compute.

Authentication options by platform

| Platform | Typical credentials | |---|---| | Claude API | API keys per workspace (ANTHROPIC_API_KEY); OAuth profiles via the ant CLI; workload identity federation for cloud workloads; Admin API keys for organization management | | OpenAI API | Project-scoped API keys (OPENAI_API_KEY), service accounts, and workload identity (Kubernetes, Azure managed identity, GCP) in current SDKs | | Gemini Developer API | API keys (GEMINI_API_KEY or GOOGLE_API_KEY) | | Gemini Enterprise Agent Platform | Google Cloud IAM and Application Default Credentials; no API key | | Amazon Bedrock / Claude Platform on AWS | AWS IAM (SigV4), roles for workloads | | Microsoft Foundry | API keys or Microsoft Entra ID |

Prefer short-lived, identity-based credentials (workload identity, cloud IAM roles) for servers. Keep static keys for local development and simple deployments, and scope them tightly.

Organizational structure

  • Separate workspaces/projects per environment (dev, staging, prod) and per product. Separate keys make rotation, cost tracking and rate-limit isolation easier.
  • Set spend limits and alerts per project where the platform supports it.
  • Give each service its own key or identity; never share one key across teams.
  • Restrict who can create keys; review keys quarterly and delete unused ones.

Storing and using secrets

  • Development: .env files loaded with a library such as python-dotenv, listed in .gitignore.
  • Production: a secret manager (AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault, or your platform's secrets), injected as environment variables or fetched at start-up.
  • CI: the CI system's encrypted secrets; never echo them in logs.
  • Rotation: automate it; design your services to pick up new keys without redeploying code.

Never put provider keys in the browser or mobile apps

Front-end code is public. Route all model calls through your backend, which authenticates your users, applies rate limits and budgets, and holds the provider key. If you need client-side realtime features, use the provider's ephemeral or session-token mechanisms where offered, minted by your backend with short lifetimes.

Worked example: a Dubai agency with 40 client projects

Problem: one shared key used by every developer and every client project; a contractor's laptop was lost, and the monthly bill spiked.

Fix:

  1. One project/workspace per client and environment; spend alerts per project.
  2. Production services use workload identity on their cloud; no static keys in prod.
  3. Developers use personal dev keys with low limits.
  4. Secret scanning on all repositories and a pre-commit hook.
  5. Quarterly key review and automatic rotation.

Result: a leaked key now has a small blast radius, and per-client costs are visible for billing.

Hands-on: safe key loading and a leak guard

# pip install python-dotenv
import os, re, sys
from dotenv import load_dotenv

load_dotenv()   # dev only; production injects env vars from a secret manager

REQUIRED = ["ANTHROPIC_API_KEY", "OPENAI_API_KEY", "GEMINI_API_KEY"]
missing = [k for k in REQUIRED if not os.environ.get(k)]
if missing:
    sys.exit(f"Missing secrets: {', '.join(missing)} (set them in .env locally or your secret manager)")

KEY_PATTERNS = [r"sk-ant-[A-Za-z0-9_\-]{20,}", r"sk-[A-Za-z0-9_\-]{20,}", r"AIza[0-9A-Za-z_\-]{30,}"]

def redact(text: str) -> str:
    """Redact anything that looks like an API key before logging."""
    for p in KEY_PATTERNS:
        text = re.sub(p, "[REDACTED_KEY]", text)
    return text

print(redact("debug: using key sk-ant-abc123abc123abc123abc123"))   # -> debug: using key [REDACTED_KEY]

Add a secret scanner (for example your code host's built-in secret scanning, or tools like gitleaks) to CI so leaks are blocked before merge. Key formats change; treat the regexes as a safety net, not a guarantee.

Incident response for a leaked key

  1. Revoke the key in the provider console immediately.
  2. Issue a replacement through your secret manager and redeploy.
  3. Review usage and billing since the likely leak time.
  4. Find and close the leak path (commit history, logs, screenshots, shared docs); purge from history if needed.
  5. Record the incident and the prevention step you added.

Pitfalls

  • Keys in front-end bundles or mobile apps.
  • One key for all environments and teams.
  • Keys pasted into chat tools, tickets or prompts.
  • No spend limits, so a leak becomes a large bill before anyone notices.

Measuring success

Number of static keys in production (drive toward zero), time to rotate all keys, secrets found by scanners (and time to revoke), and per-project spend visibility.

Video lecture: API keys, authentication and secrets management

Lecture coming soon · 15 chapters · about 9 minutes. Read the full transcript below.

  1. API keys and secrets
  2. Why it matters
  3. Auth by platform
  4. Workload identity, simply
  5. Organize keys
  6. Where keys live
  7. Simple example: portfolio chatbot
  8. Business example: Dubai agency
  9. First hour after a leak
  10. Hands-on safety nets
  11. Common mistakes
  12. Make secure the easy path
  13. Deeper: the Dubai cleanup (illustrative)
  14. Watch me do it: safe key loading
  15. Recap + try this now

Lecture transcript

API keys and secrets

Here's a story that repeats every week somewhere. A developer pushes code to a public repository with an AI API key inside. Within minutes, automated scanners find it, and by morning there's a bill for thousands of dollars in someone else's compute. In this lesson, you'll learn how to authenticate to AI platforms safely, organize keys, and make sure a leak is a small problem instead of a crisis.

Why it matters

Why does this matter so much? Because an API key is a bearer credential, like cash. Whoever holds it can spend it, no questions asked. Think of your house keys. You wouldn't tape a copy to the front door, give the same key to every contractor, or never change the locks after losing one. Yet that's exactly how many teams treat AI keys: one shared key, pasted everywhere, never rotated.

Auth by platform

Each platform authenticates differently. The Claude API uses workspace API keys, plus options like OAuth profiles through its command line tool and workload identity federation for cloud services. OpenAI uses project scoped keys, service accounts, and workload identity in its current SDKs. The Gemini Developer API uses an API key, while Google's enterprise platform uses cloud identity and application default credentials. Bedrock uses AWS identity, and Microsoft Foundry supports keys or Entra ID. The rule: for servers, prefer short lived identity based credentials over static keys.

Workload identity, simply

Let's make workload identity concrete, because it sounds more complicated than it is. Instead of storing a long lived key, your service proves who it is using the identity its cloud already gives it, like a Kubernetes service account or an Azure managed identity. The AI platform trusts that identity and hands back a short lived token that expires on its own. Think of a hotel key card that stops working at checkout, versus a metal key that works forever. If someone steals the card after checkout, it's useless. Current OpenAI and Anthropic SDKs both support identity federation for servers; check their docs for your cloud.

Organize keys

Organize before you scale. Create separate projects or workspaces for each environment, development, staging and production, and for each product or client. Set spend limits and alerts where the platform allows. Give each service its own key or identity. Restrict who can create keys, and review them every quarter. It feels like admin work, but it's what lets you answer two questions instantly: what did this client cost us, and what breaks if this key leaks?

Where keys live

Where should keys live? In development, a dot env file loaded by a small library and listed in your git ignore file. In production, a secret manager, like AWS Secrets Manager, Azure Key Vault, Google Secret Manager or Vault, injected as environment variables. In CI, the platform's encrypted secrets. And the golden rule: never put provider keys in a browser or mobile app. Front end code is public. Your backend holds the key, authenticates your users and enforces budgets.

Simple example: portfolio chatbot

A simple example. You're building a small chatbot for your portfolio site. The tempting shortcut is calling the model API straight from your JavaScript with the key embedded. Instead, you write a tiny backend endpoint that receives the user's message, checks a rate limit, calls the model with the key from an environment variable, and returns the reply. Ten extra lines of code, and your key never leaves your server.

Business example: Dubai agency

Now a realistic business example. A Dubai agency with forty client projects used one shared key for every developer and client. A contractor's laptop was lost, and the monthly bill spiked. Their fix: one project per client and environment with spend alerts, workload identity for production services, personal low limit keys for developers, secret scanning on every repository, and automatic quarterly rotation. Now a leaked key has a small blast radius, and they can bill clients accurately for AI usage.

First hour after a leak

What should you do in the first hour after a key leaks? First, revoke the key in the provider console, immediately, before investigating. Second, create a replacement and deploy it through your secret manager. Third, check usage dashboards for unusual spend or activity since the leak. Fourth, find how it leaked: a commit, a log, a screenshot, a shared document, and close that path. Finally, write two lines in your incident log. Teams that practice this once, with a fake key, handle the real thing calmly in minutes.

Hands-on safety nets

The lesson's code shows two small safety nets. It refuses to start if required secrets are missing, with a helpful message. And it redacts anything that looks like an API key before logging. Key formats change, so treat patterns as a safety net, not a guarantee. Pair them with a secret scanner in CI that blocks merges containing keys.

Common mistakes

Common mistakes to avoid. Keys in front end bundles or mobile apps. One key for every environment and team. Keys pasted into chat tools, tickets, or even prompts. And no spend limits, so a leak becomes a huge bill before anyone notices. Each of these is cheap to prevent and expensive to discover.

Make secure the easy path

A final practical tip: make the secure path the easy path. Give developers a one line command or script that fetches their personal development key from the secret manager into their local environment. Provide a project template that already has the dot env file ignored, the secret scanner configured, and a backend endpoint pattern for model calls. When doing the right thing takes less effort than the shortcut, people stop taking shortcuts, and you stop finding keys in chat threads.

Deeper: the Dubai cleanup (illustrative)

Let's deepen the Dubai agency's cleanup with illustrative numbers. They found keys in three repositories, two shared documents and one chat channel. After the reorganisation, forty client projects each had their own workspace and spend alert. Two months later, a contractor accidentally pasted a development key into a public gist. The secret scanner alerted within minutes, the key was revoked in the provider console, and because it was a low limit development key in one client's project, the potential spend was capped at a few dollars. Finance could also, for the first time, invoice AI usage per client accurately, which more than paid for the half day the cleanup took.

Watch me do it: safe key loading

Watch me do it. Let's walk through the safe loading script. First, load dot env reads a local dot env file, which I only use in development; in production the variables come from the secret manager. Next, a required list names the three provider keys, and I compute which are missing. If any are, the script exits immediately with a message naming them and saying where to set them. That's much better than failing later with a confusing authentication error. Then the redaction helper: a list of patterns for Anthropic, OpenAI and Google style keys. Redact loops over them and replaces any match with redacted key. I call it on a debug line containing a fake key, and the output shows the placeholder instead. Every log call in the service goes through this function. Finally, I'd add a secret scanner to CI so a key never reaches the main branch in the first place.

Recap + try this now

Quick recap. Keys are bearer credentials. Prefer identity based access for servers, separate projects by environment and client, store secrets in a manager, never ship keys to front ends, and automate scanning and rotation. Try this now: find every place your AI keys live today. Move one service to a secret manager or workload identity, add secret scanning to one repository, and set a spend alert on your production project.

Key takeaways

  • API keys are bearer credentials: whoever holds one can spend your money.
  • Prefer workload identity and cloud IAM for servers; keep static keys scoped and short-lived.
  • Separate projects per environment and product, with spend limits and alerts.
  • Never ship provider keys to browsers or mobile apps; call models from your backend.
  • Automate secret scanning, redaction and rotation.

Try it

Audit where your AI keys live today. Move one service to a secret manager or workload identity, add secret scanning to one repository, and set a spend alert.