API-Keys besorgen und sicher verwalten

Warum der API-Key mehr Aufmerksamkeit verdient als der Chat-Zugang

Ein API-Key ist kein Passwort im klassischen Sinn - er ist eher wie ein Blankoscheck mit deinem Namen drauf. Wer den Key hat, kann in deinem Namen Anfragen an OpenAI, Anthropic, Google oder OpenRouter schicken, und du bezahlst die Rechnung. Anders als bei einem Website-Login gibt es meistens keine Zwei-Faktor-Abfrage bei jeder Nutzung - der Key allein reicht.

Genau deshalb lohnt es sich, das Thema einmal grundlegend zu verstehen, bevor du das erste eigene KI-Projekt oder Skript baust: Wo bekommst du die Keys her, wie speicherst du sie, wie begrenzt du den moeglichen Schaden, und was tust du, wenn doch mal einer nach aussen dringt.

Wo du die Keys herbekommst

Jeder Anbieter hat ein eigenes Entwickler-Dashboard, in dem Keys generiert werden. Ein Konto (meist per E-Mail oder Google-Login) und in der Regel eine hinterlegte Zahlungsmethode sind Voraussetzung, sobald du ueber ein kostenloses Kontingent hinausgehst.

Ein Key sieht je nach Anbieter unterschiedlich aus, folgt aber immer demselben Prinzip: eine lange, zufaellige Zeichenkette mit erkennbarem Praefix, zum Beispiel sk-... bei OpenAI oder sk-ant-api03-... bei Anthropic. Das Praefix hilft unter anderem automatisierten Scannern (etwa bei GitHub), Leaks ueberhaupt als solche zu erkennen.

Sicher speichern: die Grundregel

Die wichtigste Regel zuerst, weil sie die meisten Leaks verhindert: Ein API-Key gehoert nie in Code, nie in einen Chat-Verlauf und nie in ein Git-Repository - auch nicht in ein privates. Sobald ein Key einmal committet wurde, gilt er als kompromittiert, selbst wenn du den Commit spaeter loeschst, denn die Git-Historie bleibt lokal und in Forks bestehen, und Scanner durchsuchen oft auch alte Commits.

Stattdessen gilt fuer alle vier Anbieter derselbe Grundmechanismus: Der Key wird als Umgebungsvariable gesetzt und vom Code zur Laufzeit ausgelesen, nie fest im Quelltext hinterlegt (“hartkodiert”).

# macOS/Linux: temporaer fuer die aktuelle Sitzung
export OPENAI_API_KEY="dein-key-hier"
export ANTHROPIC_API_KEY="dein-key-hier"

# Windows PowerShell: dauerhaft fuer den aktuellen Benutzer
setx OPENAI_API_KEY "dein-key-hier"
setx ANTHROPIC_API_KEY "dein-key-hier"

Fuer lokale Projekte hat sich die .env-Datei etabliert: eine einfache Textdatei im Projektordner mit SCHLUESSEL=wert-Zeilen, die von Bibliotheken wie python-dotenv oder dotenv in Node.js automatisch eingelesen wird. Entscheidend ist dabei ein einziger Schritt, der oft vergessen geht:

# .gitignore - unbedingt VOR dem ersten Commit anlegen
.env
.env.local
*.env

Naechste Stufe: Secret-Manager

Fuer alles, was ueber ein Hobbyprojekt hinausgeht - vor allem fuer Server, CI/CD-Pipelines oder Firmenprojekte - ist eine .env-Datei nur die Einstiegsloesung. Sie liegt trotzdem als Klartext auf der Platte, kann versehentlich in ein Backup, einen Docker-Build-Kontext oder eine Log-Ausgabe geraten. Fuer produktive Umgebungen sind dedizierte Secret-Manager der naechste Schritt:

• Cloud-eigene Loesungen: AWS Secrets Manager, Google Secret Manager, Azure Key Vault
• Plattform-eigene Loesungen: GitHub Actions Secrets, Cloudflare Workers Secrets (wrangler secret put), Vercel Environment Variables
• Eigenstaendige Tools: HashiCorp Vault, Doppler, 1Password (mit CLI-Integration)

Der gemeinsame Vorteil: Der Klartext-Key liegt nur verschluesselt und Zugriffs-kontrolliert im Manager, wird zur Laufzeit injiziert und taucht in keinem Repository, Backup oder Log auf.

Anthropic geht bei produktiven Workloads noch einen Schritt weiter und bietet Workload Identity Federation an: Statt eines statischen Keys authentifiziert sich der Dienst ueber einen kurzlebigen Token, den er von einem bereits vertrauten Identitaetsanbieter (AWS IAM, Google Cloud, GitHub Actions, Kubernetes, Okta) bezieht. Es gibt dann gar keinen langlebigen sk-ant-...-String mehr, der geleakt werden koennte - der SDK erneuert den Token automatisch im Hintergrund.

Key-Scopes, Projekte und Workspaces

Alle vier Anbieter erlauben es inzwischen, Keys nicht nur zu benennen, sondern auch inhaltlich einzugrenzen, damit ein einzelner kompromittierter Key nicht gleich Zugriff auf alles gibt:

Rate-Limits und Budget-Limits setzen

Ohne Gegenmassnahme kann ein fehlerhaftes Skript (etwa eine Endlosschleife, die bei jedem Durchlauf einen API-Call ausloest) innerhalb weniger Minuten eine vierstellige Rechnung verursachen. Deshalb bieten alle Anbieter zwei Arten von Begrenzung:

• Rate-Limits begrenzen, wie viele Anfragen oder Tokens pro Minute verarbeitet werden (bei Anthropic z. B. “Requests per minute” und “Tokens per minute”, organisiert in Nutzungs-Stufen/Tiers, die mit steigendem Verbrauch automatisch hochgestuft werden). Sie schuetzen primaer die Infrastruktur des Anbieters, begrenzen aber als Nebeneffekt auch das Schadenspotenzial eines ausser Kontrolle geratenen Skripts.
• Budget- bzw. Spend-Limits begrenzen die maximalen Kosten pro Monat direkt in Geld. OpenAI erlaubt in den Projekt-Einstellungen benachrichtigende Schwellenwerte sowie eigene Rate- und Spend-Limits pro Projekt. Gemini staffelt zahlungsbasierte Limits in Stufen (z. B. ein Ausgabenlimit von 10 US-Dollar pro 10-Minuten-Fenster in der niedrigsten bezahlten Stufe, das mit steigendem kumuliertem Verbrauch automatisch hochgestuft wird).

Rotation: Keys regelmaessig austauschen

“Rotation” bedeutet, einen Key nach einer festgelegten Zeit durch einen neuen zu ersetzen, unabhaengig davon, ob ein Leak bekannt ist. Der Sinn dahinter: Sollte ein Key unbemerkt abgeflossen sein (z. B. ueber ein altes Backup oder einen Log, den niemand mehr anschaut), begrenzt die Rotation das Zeitfenster, in dem er missbraucht werden kann.

Anthropic hat das direkt in den Erstellungsprozess eingebaut: Bei jedem neuen Key waehlst du eine Ablauffrist (3 Stunden bis 30 Tage, individuell, oder “Never” fuer Keys, die du selbst in einem Secret-Manager verwaltest und rotierst). Kurz vor Ablauf erhaelt die erstellende Person automatisch eine Erinnerungs-Mail. Bei OpenAI, Google und OpenRouter ist Ablauf kein automatisches Feature - Rotation musst du selbst als Prozess einplanen, etwa quartalsweise fuer produktive Keys.

Praktischer Rotations-Ablauf (fuer produktive Systeme):

1. Neuen Key erzeugen (mit sprechendem Namen, z. B. "prod-2026-q3")
2. Neuen Key im Secret-Manager/in der Umgebungsvariable hinterlegen
3. Deployment durchfuehren, mit neuem Key testen
4. Erst DANACH den alten Key widerrufen

Die Reihenfolge ist wichtig: Neuer Key zuerst aktiv, alter Key erst danach widerrufen - sonst legst du den Dienst fuer die Dauer der Umstellung lahm.

Was tun, wenn ein Key geleakt ist

Ein Leak passiert schneller als gedacht: ein versehentlicher Commit, ein Screenshot mit sichtbarem Terminal, ein Key, der in einem Support-Chat oder einer offenen Slack-Nachricht landet. Der Ablauf ist bei allen Anbietern im Kern gleich:

1. Sofort widerrufen (“Revoke”). Im jeweiligen Dashboard den betroffenen Key loeschen bzw. deaktivieren - noch bevor du ueberlegst, ob wirklich ein Missbrauch stattgefunden hat. Ein widerrufener Key ist sofort ungueltig.
2. Neuen Key erzeugen und in allen betroffenen Systemen (Secret-Manager, Umgebungsvariablen, CI/CD) austauschen.
3. Nutzung/Abrechnung pruefen. Im Usage-Dashboard des Anbieters nachsehen, ob im fraglichen Zeitraum ungewoehnliche Anfragen oder Kosten aufgetaucht sind.
4. Ursache beheben, damit sich der Leak nicht wiederholt - z. B. .gitignore nachtragen, betroffene Commits bereinigen, Team ueber sichere Speicherung informieren.

Bei Anthropic hilft zusaetzlich die bereits erwaehnte Ablauffrist: Selbst wenn ein Leak unbemerkt bleibt, verliert ein Key mit kurzer Gueltigkeit (z. B. 1 Tag) von selbst seine Wirkung. Das ersetzt das Widerrufen nicht, reduziert aber das Risiko bei Keys, die zum Beispiel nur fuer einen einmaligen Testlauf gedacht waren.

Kurzueberblick: die vier Anbieter im Vergleich

Kurz zusammengefasst

• API-Keys sind Blankoschecks mit deinem Namen - wer sie hat, verursacht Kosten in deinem Namen.
• Keys erstellst du im jeweiligen Anbieter-Dashboard (OpenAI: platform.openai.com; Anthropic: platform.claude.com; Gemini: aistudio.google.com; OpenRouter: openrouter.ai/keys).
• Nie im Code, Chat oder Repository speichern - stattdessen Umgebungsvariablen, .env plus .gitignore, fuer produktive Systeme ein dedizierter Secret-Manager.
• Rate-Limits schuetzen vor versehentlicher Ueberlastung, Budget-Limits vor unerwarteten Kosten - beide unbedingt setzen, auch beim Testen.
• Keys nach Umgebung und Projekt trennen (Dev/Staging/Prod), regelmaessig rotieren, und bei jedem Verdacht auf Leak sofort widerrufen statt abzuwarten.

Weiterlernen

• Anthropic: Authentication & API-Key-Erstellung
• Anthropic: API-Overview inkl. Rate-Limits
• Google AI Studio: API-Key-Verwaltung
• Google: Gemini-API-Rate-Limits
• OpenRouter: API-Keys-Dokumentation
• OpenAI: Production Best Practices

Verwandte Themen im Wiki: LLM-APIs: Grundlagen, Tokens & Kosten optimieren, KI-Sicherheit im Unternehmen, Shadow-AI & Governance.