Ein Tresor für meine KI-Schlüssel — und warum 2026 der richtige Moment ist

Der Moment, in dem es klick machte

Es war eine banale Aufräumaktion, die mich ins Grübeln brachte. Ich suchte in meinen Projekten nach einer alten Konfigurationsdatei — und stolperte dabei über denselben KI-API-Schlüssel gleich mehrfach: im Live-System, in einem Backup von letzter Woche, in zwei Testprofilen, die ich längst vergessen hatte. Ein und derselbe Schlüssel, verstreut über ein halbes Dutzend Stellen.

Und dann der Gedanke, der mir den Nachmittag verdarb: Wenn ich diesen Schlüssel jetzt austauschen müsste — weil er geleakt ist, weil ein Dienstleister ihn gesehen hat, weil ich einfach vorsichtig sein will — dann müsste ich jede einzelne dieser Kopien von Hand finden und ersetzen. Und die eine, die ich übersehe, bleibt gültig. Für jeden, der sie hat.

Ein KI-API-Schlüssel ist nämlich kein Passwort. Ein Passwort schützt einen Zugang. Ein API-Schlüssel ist eher eine Kreditkarte ohne Limit: Wer ihn hat, kann in meinem Namen Anfragen an teure Modelle stellen, bis das Guthaben leer oder die Rechnung schmerzhaft ist. Und ich hatte diese Kreditkarte behandelt wie Bargeld unterm Kopfkissen — an zehn Stellen gleichzeitig.

Das Problem, das jeder mit KI-Automatisierung bekommt

Ich bin mit diesem Problem nicht allein, und es ist auch keine Nachlässigkeit — es ist die natürliche Folge davon, dass KI plötzlich überall mitläuft. Jeder kleine Automatisierungs-Baustein, jedes Skript, jeder Agent, jede Anwendung braucht Zugang zu einem Modell. Also wandert der Schlüssel überallhin. Und mit jeder Kopie wächst die Angriffsfläche.

Das ist keine gefühlte Gefahr. Das Open Worldwide Application Security Project (OWASP) pflegt eine viel beachtete Rangliste der größten Sicherheitsrisiken für KI-Anwendungen. In der Ausgabe 2025 ist „Sensitive Information Disclosure“ — das ungewollte Offenlegen sensibler Daten, ausdrücklich inklusive API-Schlüssel und Zugangs-Tokens — von Platz 6 auf Platz 2 hochgeklettert.^[1] Die Kernbotschaft der OWASP-Fachleute ist unmissverständlich: Zugangsschlüssel gehören nicht dorthin, wo sie ein Modell oder ein Dienst nebenbei zu Gesicht bekommt. Sie gehören an eine geschützte Stelle, und alles andere greift nur kontrolliert darauf zu.

Genau das hatte ich nicht. Ich hatte viele Stellen. Und keine Kontrolle darüber, wer wann wie viel verbraucht.

Warum ich meinen KI-Schlüsseln ein Hotel baue

Die Lösung, auf die ich kam, lässt sich am besten mit einem Hotel erklären.

In einem gut geführten Hotel gibt es genau einen Generalschlüssel, der jede Tür öffnet. Der liegt im Tresor und verlässt ihn nie. Die Gäste bekommen keine Kopie davon — sie bekommen Zimmerkarten: Jede öffnet nur ein Zimmer, gilt nur für die Dauer des Aufenthalts, und wenn eine verloren geht, sperrt die Rezeption in Sekunden genau diese eine Karte. Der Generalschlüssel bleibt davon völlig unberührt.

Übertragen auf meine KI-Schlüssel heißt das: Es gibt künftig eine einzige Stelle in meinem Netzwerk — nennen wir sie den Tresor —, die die echten Anbieter-Schlüssel kennt. Sonst niemand. Jede Anwendung, jeder Agent bekommt stattdessen eine „Zimmerkarte“: einen eigenen, widerrufbaren Zugangs-Token mit einem festen Budget, einer Liste erlaubter Modelle und einem Ablaufdatum. Läuft eine Anwendung Amok oder gerät ein Token in falsche Hände, sperre ich diese eine Karte — der Rest läuft weiter, und der echte Schlüssel war nie in Gefahr.

Und zum ersten Mal sehe ich auf einen Blick, welche Anwendung wie viel verbraucht.

Warum gerade jetzt

Dass ich mir diese Frage ausgerechnet in diesem Sommer stelle, ist kein Zufall. Am 2. August 2026 wird ein zentraler Teil der europäischen KI-Verordnung (Verordnung (EU) 2024/1689, der „AI Act“) wirksam: die Transparenzpflichten nach Artikel 50 — etwa die Pflicht, KI-Chatbots als solche kenntlich zu machen und KI-generierte Inhalte zu kennzeichnen.^[2] Die viel diskutierten Pflichten für „Hochrisiko“-Systeme wurden übrigens jüngst verschoben — durch den sogenannten „Digital Omnibus“ vom Juli 2026 gelten sie erst später.^[3] Wer online etwas anderes liest, liest womöglich einen veralteten Stand.

Mir geht es dabei nicht um Pflichterfüllung — ein Schlüssel-Tresor ist keine Vorgabe des AI Act, und ich will hier niemandem einreden, er müsse jetzt etwas bauen. Was mich am Datum interessiert, ist der Geist dahinter: Nachvollziehbarkeit, Kontrolle, Verantwortung für das, was die eigene KI tut. Der Gesetzgeber macht Transparenz zur Regel für alle. Ich habe mir dieselbe Frage einfach für meine eigene Infrastruktur gestellt — freiwillig, aus demselben Grund: Ich will wissen und steuern können, wer in meinem Namen mit KI arbeitet.

Wie ich es baue — mit Open Source

Das Schöne ist: Man muss so einen Tresor nicht von Grund auf erfinden. Als Motor nutze ich LiteLLM, ein quelloffenes Projekt unter der freizügigen MIT-Lizenz.^[4] Es stellt eine einzige, standardisierte Schnittstelle bereit, hinter der sich über hundert verschiedene KI-Anbieter verbergen können, und bringt genau die Tresor-Funktionen mit, die ich brauche: virtuelle Zugangs-Tokens, Budgets pro Token, Ratenlimits, erlaubte Modell-Listen und eine lückenlose Verbrauchsübersicht.^[4]

Entscheidend für mich: Ich betreibe das Ganze selbst, im eigenen Netz. Der Tresor läuft auf meiner Hardware, die echten Schlüssel liegen verschlüsselt bei mir, und keine Anfrage verlässt meinen Kontrollbereich, ohne dass ich es nachvollziehen kann. Souveränität ist hier kein Marketingwort, sondern eine ganz praktische Eigenschaft: Der Generalschlüssel liegt in meinem Tresor, nicht in einer fremden Cloud.

Wie es weitergeht

Noch ist der Tresor im Aufbau. Der nächste Schritt ist der erste echte Testaufruf — der Moment, in dem zum ersten Mal eine Anfrage durch den Tresor läuft und eine Antwort zurückkommt, ohne dass der echte Schlüssel jemals das Gerät berührt hat, das sie gestellt hat. Danach zieht die erste reale Anwendung um, vorsichtig, mit dem alten Schlüssel als Rückweg in der Hinterhand.

Ich werde berichten, wie sich das im Alltag anfühlt — was funktioniert, was hakt, was ich unterschätzt habe. Genau dafür steht mvxlabs: nicht über KI reden, sondern sie an echten Dingen ausprobieren und ehrlich aufschreiben, was dabei herauskommt.

Quellenverzeichnis

Die genannten Fakten und Daten wurden im August 2026 direkt an den offiziellen bzw. maßgeblichen Quellen geprüft:

1. OWASP — Top 10 for LLM Applications 2025, Risiko „LLM02: Sensitive Information Disclosure“: owasp.org/www-project-top-10-for-large-language-model-applications (Aufstieg von Platz 6 auf Platz 2; nennt API-Schlüssel und Zugangs-Tokens ausdrücklich; Empfehlung, Zugangsdaten außerhalb des Prompts zu halten). Abruf 01.08.2026.
2. Europäische Union — Verordnung (EU) 2024/1689 („AI Act“), Artikel 50 (Transparenzpflichten): eur-lex.europa.eu/eli/reg/2024/1689 · Einordnung: artificialintelligenceact.eu/transparency-rules-article-50 (Transparenzpflichten anwendbar ab 02.08.2026). Abruf 01.08.2026.
3. Zur Verschiebung der Hochrisiko-Pflichten durch den „Digital Omnibus on AI“ (Juli 2026): technology.org — What Actually Applies on 2 August 2026 (eigenständige Anhang-III-Systeme bis 02.12.2027, in Produkte eingebettete Systeme nach Anhang I bis 02.08.2028). Abruf 01.08.2026.
4. LiteLLM — quelloffener AI-Gateway/LLM-Proxy: litellm.ai · Dokumentation: docs.litellm.ai/docs/simple_proxy (MIT-Lizenz; eine OpenAI-kompatible Schnittstelle zu über hundert Anbietern; virtuelle Schlüssel mit eigenem Budget, Ratenlimits und Modell-Zugriffsbeschränkung). Abruf 01.08.2026.