Hör auf, API-Keys in Agenten-Configs zu kleben
Irgendwo auf einem Laptop in deinem Team liegt eine Konfigdatei mit einem Stapel API-Keys im Klartext. Wer dieses Jahr KI-Agenten mit echten Tools verbunden hat, kennt die Datei: die MCP-Config, die .env daneben, das Notiz-Dokument, in dem Keys "vorübergehend" wohnen. API-Keys in Agenten-Configs zu kleben ist der Einstieg fast aller, und es ist ein Anti-Muster, das sich mit jedem weiteren Tool verzinst.
Warum API-Keys und KI-Agenten sich schlecht vertragen
Ein API-Key an sich ist nicht böse. Er ist ein brauchbares Credential für einen Server, der mit einem Dienst spricht: bewusst erzeugt, in einem Secrets-Manager gespeichert, nach Plan rotiert. Das Problem: Agenten-Setups haben keine dieser Eigenschaften.
- Agenten vervielfachen Keys. Jedes Tool, das dein Agent anfasst, will sein eigenes Credential. Zehn Tools heißt zehn langlebige Geheimnisse in einer JSON-Datei.
- Die Datei reist. Agenten-Configs werden in Dotfiles gesynct, zur Hilfe in den Chat kopiert, am Bildschirm geteilt und gelegentlich in ein Repo committet. Jede Kopie ist ein vollwertiges Credential.
- Keys sind account-weit, nicht aufgaben-weit. Ein Agent, der nur Support-Tickets lesen muss, hält meist einen Key, der sie auch löschen kann, weil der Dienst nur diese Sorte ausgibt.
- Niemand rotiert sie. Rotation macht den Agenten kaputt, und niemand weiß mehr, wo all die Kopien liegen. Die ehrliche Antwort auf "wann wurde der zuletzt rotiert" ist meistens "nie".
- Hinter dem Aufruf steht keine Identität. Das SaaS loggt "der Key war es", nicht "der Agent, im Auftrag dieser Person". Wenn etwas schiefgeht, sagt dir das Log nichts Brauchbares.
Die meisten Ratschläge zur MCP-API-Key-Sicherheit drehen sich um Transport: HTTPS nutzen, Geheimnisse aus dem Repo halten. Nötig, aber am strukturellen Punkt vorbei. Das Credential selbst hat die falsche Form für den Job. (Die Protokoll-Sicht, Transports und Auth-Flows, steht in [MCP-Sicherheit](/de/blog/mcp-security-basics).)
Ein realistischer Schadensfall, ganz ohne Drama
Ein Contractor hilft dir im März, einen Agenten-Workflow zu verdrahten. Damit es läuft, schickt ihm jemand den CRM-Key per Chat. Er klebt ihn in die Config auf seiner Maschine, das Projekt liefert, der Vertrag endet.
Jetzt ist Juli. Der Key funktioniert noch. Er hat noch vollen Account-Zugriff, weil das CRM auf deinem Plan nur Vollzugriffs-Keys ausgibt. Er existiert in einem Chat-Verlauf, auf einem Laptop, den du nicht kontrollierst, und in einer Config, die der Contractor vergessen hat. Noch hat niemand etwas falsch gemacht, und genau das ist das Unangenehme. Es gibt keinen Einbruch zu entdecken. Es gibt nur stehenden Zugriff ohne Besitzer, ohne Ablauf und ohne Sicht darauf, ob er benutzt wird.
Die meisten Key-Vorfälle sehen so aus. Kein Hack, auf den man zeigen kann, sondern Zugriff, an dessen Vergabe sich niemand erinnert.
OAuth vs. API-Keys für Agenten
Die Alternative ist nicht exotisch. Es ist derselbe Ablauf wie bei einer App, die deinen Kalender sehen will: beim Anbieter anmelden, Zustimmungsbildschirm lesen, konkrete Scopes freigeben.
| Frage | Eingeklebter API-Key | OAuth-Verbindung |
|---|---|---|
| Wer hat zugestimmt? | Wer auch immer geklebt hat, ohne Aufzeichnung | Ein Zustimmungsbildschirm, an einen Nutzer gebunden |
| Was kann er? | Alles, was der Account kann | Die gewährten Scopes, nichts darüber hinaus |
| Wo lebt das Geheimnis? | Klartext, in jeder Kopie der Datei | Serverseitig, als widerrufbares Token |
| Wie stirbt er? | Jemand erinnert sich ans Löschen | Ein Klick widerruft diese Verbindung |
| Was zeigt das Log? | "Der Key war es" | Welche Verbindung, für welchen Nutzer |
Auch OAuth-Tokens können lecken; das ist keine Magie. Der Unterschied ist der Lebenszyklus. Zustimmung beim Erzeugen, Scope beim Gewähren, Widerruf nach Belieben. Ein geklebter Key hat davon nichts, und keine noch so sorgfältige Handhabung rüstet es nach.
Wie gut aussieht: Zustimmung, Vault, Widerruf
Zustimmung statt Kleben. Jede Verbindung beginnt mit einem Zustimmungsbildschirm, der die Scopes benennt. Die zustimmende Person sieht genau, was der Agent bekommt, und die Freigabe wird ihrer Identität zugeordnet, statt frei zu schweben.
Ein Vault statt einer Datei. Geheimnisse, ob OAuth-Tokens oder die API-Keys, um die du wirklich nicht herumkommst, leben verschlüsselt serverseitig und werden nur im Moment eines Aufrufs entschlüsselt. Sie liegen nie auf Laptops, in Dotfiles oder Repos. Wenn ein Key das Einzige ist, was ein Anbieter hergibt, schlägt eine Kopie im Vault fünf Kopien in Configs.
Widerruf mit Spur. Du kannst eine Verbindung töten, ohne alles andere zu rotieren, und es gibt einen [Audit-Trail dessen, was der Agent wirklich aufgerufen hat](/de/blog/ai-agent-audit-trail). "Was hat dieses Credential getan" wird mit einer Liste beantwortet statt mit einem Schulterzucken.
Wo ein Gateway ins Bild kommt
Das ist das praktischste Argument für ein [MCP Gateway](/de/gateway) zwischen deinen Agenten und deinen Tools: Das Credential-Problem wird einmal zentral gelöst statt einmal pro Konfigdatei. Du verbindest jedes Tool ein einziges Mal, per OAuth, wo der Anbieter es unterstützt, per API-Key in einen verschlüsselten Vault, wo nicht. Agenten sprechen mit einem Endpunkt, und jede Verbindung bleibt einzeln widerrufbar. Das größere Modell steht in [MCP-Gateway-Sicherheit](/de/blog/mcp-gateway-security).
Nach diesem Modell haben wir auch Tulimoas Gateway gebaut: OAuth-Login, ein verschlüsselter Vault pro Geheimnis, Nutzung nur im Moment des Aufrufs, Widerruf pro Verbindung. Es ist in früher Beta und noch nicht self-serve, nimm also das Muster mit, nicht den Pitch. Jedes Setup mit Zustimmung, Vault und Widerruf schlägt einen Ordner voller geklebter Keys, egal wer es baut.
Mach das heute
Du brauchst keine neue Infrastruktur für den Start. Du brauchst eine Inventur.
Schritt 1: Öffne jede Agenten-Config auf deinen Maschinen und zähl die Credentials, .env-Dateien eingeschlossen.
Schritt 2: Beantworte für jeden Key vier Fragen: Wer hat ihn erzeugt, worauf hat er Zugriff, wann wurde er zuletzt rotiert, und wie würdest du ihn in den nächsten fünf Minuten töten, wenn du müsstest?
Schritt 3: Jeder Key mit einem "weiß ich nicht" daran ist dein erster Zug. Rotiere ihn, begrenze ihn, wenn der Anbieter es erlaubt, und leg den Ersatz verschlüsselt ab, mit benanntem Besitzer.
Die Keys, für die du keine Antworten hast, sind kein hypothetisches Risiko. Sie sind stehender Zugriff, heute, auf Maschinen, die dir vielleicht nicht gehören. Fang dort an.