Tresor für Geheimnisse: Ihre KI nutzt Schlüssel, ohne sie zu sehen

Eine kleine Übung zum Einstieg. Öffnen Sie Ihr E-Mail-Postfach, geben Sie „Passwort“ in die Suchleiste ein und sehen Sie sich an, was auftaucht. Nur zu, ich warte.

Und? Ein Administratorzugang, vor zwei Jahren „vorübergehend“ verschickt, ein API-Schlüssel, in einen Team-Chat kopiert, eine Tabelle „Zugänge“, die mit dem halben Unternehmen geteilt ist? Keine Sorge, Sie sind in großer Gesellschaft. Laut dem GitGuardian-Bericht 2026 über die Ausbreitung von Geheimnissen finden 28 % der Lecks von Geheimnissen ausschließlich außerhalb von Code-Repositorys statt, in Kollaborations- und Produktivitätswerkzeugen. Geheimnisse sind im Fachjargon all die Passwörter, API-Schlüssel und Zugriffstoken, die einer Person oder einer Maschine Ihre Werkzeuge öffnen.

Bisher war das Problem vor allem menschlich. Mit KI-Agenten ändert sich die Größenordnung: Man vertraut ihnen Schlüssel an, damit sie allein arbeiten, und ein Agent liest alles, kopiert alles und gehorcht manchmal irgendwem. Dieser Text aus unserer Rubrik Unternehmens-KI erzählt von den Lecks, denen wir in den letzten Monaten begegnet sind, was KI daran ändert, und von der Lösung, die wir vorschlagen: einem Tresor, dessen Schlüssel Sie behalten und den Ihre KI nutzt, ohne die Schlüssel je zu sehen. Und den nicht einmal wir öffnen. Kleiner Spoiler: Die Antwort ist nicht, den Schlüssel unter der Fußmatte zu verstecken.

Kurz gesagt

• Geheimnisse sickern überall durch: 28,65 Millionen neue Geheimnisse im Klartext auf dem öffentlichen GitHub im Jahr 2025, ein Plus von 34 % gegenüber dem Vorjahr. Offengelegte Schlüssel von KI-Diensten stiegen um 81 %.
• Ein offengelegter Schlüssel bleibt es lange: 64 % der 2022 entdeckten gültigen Geheimnisse funktionierten vier Jahre später noch.
• KI-Agenten verändern die Größenordnung des Risikos: Ein Agent, der einen Schlüssel liest, kann ihn wiederholen, kopieren oder sich ihn durch eine präparierte Anweisung entlocken lassen.
• Die Abwehr passt in ein Prinzip: Der Agent fordert eine Aktion an, ein Relais fügt den Schlüssel im Moment des Aufrufs hinzu, und das Modell sieht ihn nie.
• Der Tresor läuft auf Ihren Namen, unsere Zugänge verschwinden bei der Übergabe, und jeder Schlüssel, den wir während des Projekts gesehen haben könnten, wird geändert.

Wo liegen Ihre Passwörter und API-Schlüssel herum?

Überall dort, wo es im Moment praktisch war. Das ist die ganze Mechanik des Lecks: Niemand beschließt, einen Schlüssel zu veröffentlichen. Er landet dort, wo er gerade hilft, und wird vergessen.

Hier ist, was wir in den letzten Monaten gefunden haben. Nichts Exotisches, und genau das ist beunruhigend.

Der Dreifachtreffer, in einem einzigen Projekt. Im Juli förderte das Audit eines Projekts, das wir begleiten, einen Administrationsschlüssel für das CRM zutage, mit allen Rechten (lesen, ändern, löschen), im Klartext in einem Skript, das im Code-Repository gespeichert war. Das Skript trug einen Namen, der versprach, alles zu löschen, und der Schlüssel lief in etwa hundert Jahren ab. Vorausschauend. Dasselbe Audit fand eine lokale Konfigurationsdatei, die auf dem Rechner eines Entwicklers bleiben sollte, aber von der Historie des Repositorys erfasst wurde. Und diesen Herbst stießen wir bei der Neuaufnahme des technischen Inventars desselben Projekts auf das Administratorpasswort eines Werkzeugs, ausgeschrieben in einer Installationsanleitung, die beim Code lag.

Das Gegenmittel ist immer dasselbe:

Merken Sie sich die Regel: Ein Schlüssel, der sichtbar war, ist ein toter Schlüssel.

Die grüne Veröffentlichungskette, die nichts veröffentlichte. Bei einem anderen Kunden fehlten der automatischen Veröffentlichungskette ihre Geheimnisse. Ergebnis: Alles leuchtete grün, nichts ging online, und niemand bemerkte es. Ein schlecht verwahrtes Geheimnis macht nicht immer Lärm, wenn es fällt.

Und bei uns? An dem Tag, an dem wir beschlossen, alle unsere Agenten in der Cloud statt auf einem Computer laufen zu lassen, lagen manche Schlüssel noch in einer Datei auf dem Rechner des Gründers. Eine einzige Maschine fällt aus, und niemand weiß mehr, wo die Schlüssel sind oder welche zu ändern sind. Die Agenten konnten sie dagegen nicht mehr lesen, und das war gut so: Ein Schlüssel, den der Agent nie gesehen hat, ist ein Schlüssel, den er nicht durchsickern lassen kann. Alles Folgende geht davon aus.

Die ANSSI, die französische Behörde für Cybersicherheit, hatte bereits im Oktober 2021 alles in einer Zeile gesagt, in ihren Empfehlungen zur Authentifizierung und zu Passwörtern:

Deutlicher geht es kaum.

Warum verändern KI-Agenten die Größenordnung des Problems?

Ein Mensch, der ein Passwort vor Augen hat, sagt es einem Unbekannten nicht auf (in der Regel). Ein KI-Agent schon. Nicht aus Bosheit: Er liest alles, was man ihm gibt, führt Anweisungen aus und unterscheidet nicht immer zwischen Ihren und denen, die ein Schlaumeier in eine E-Mail oder ein Ticket geschmuggelt hat. Wenn Ihnen die Funktionsweise eines Agenten noch unklar ist, zerlegt unser Artikel über die Schleife eines KI-Agenten sie Stück für Stück.

Drei wahre Geschichten zur Einordnung.

Wenn der Angriff die KI des Opfers arbeiten lässt. Am 26. August 2025 wurden präparierte Versionen von Nx veröffentlicht, einem weit verbreiteten Entwicklungswerkzeug. Laut der Analyse von Wiz wies der Schadcode die auf dem Rechner installierten Programmierassistenten an, mit den Optionen, die ihre Schutzmechanismen deaktivieren, die Festplatte nach Kryptowallets, SSH-Schlüsseln und Konfigurationsdateien zu durchsuchen. Die Bilanz, in zwei Wellen:

Die KI war nicht die Schwachstelle. Sie diente als Trüffelhund.

Wenn der Agent die Schlüssel in ein Ticket kopiert. Im Juli 2025 zeigten Forscher von General Analysis, und Simon Willison berichtete darüber, wie ein Programmieragent, der mit Administratorrechten an eine Datenbank angeschlossen war, durch ein einfaches Support-Ticket ausgetrickst werden konnte. Das Ticket enthielt versteckte Anweisungen. Beim Lesen konnte der Agent den Inhalt einer Tabelle mit Integrationstoken in eine Antwort kopieren, die der Angreifer sehen konnte. Es ist eine Demonstration, kein Vorfall, aber das Szenario ist von einer Banalität, die einem den Rücken hinunterläuft. Simon Willison gab ihm einen Namen:

Wenn ein gestohlener KI-Schlüssel 46 000 Dollar pro Tag kosten kann. Im Mai 2024 beschrieb das Forschungsteam von Sysdig das „LLMjacking“: Angreifer stehlen Cloud-Zugangsdaten, um gehostete KI-Modelle zu nutzen und den Zugang weiterzuverkaufen, auf Kosten des Opfers. Im schlimmsten von Sysdig berechneten Fall übersteigt die Rechnung 46 000 Dollar Verbrauch pro Tag. Ein herumliegender KI-Schlüssel ist eine Kreditkarte, die ans Schaufenster geklebt ist. Und hochwertige KI wird nicht billiger: Das teuerste ChatGPT-Abo ist in dreieinhalb Jahren von 20 auf 500 Dollar pro Monat gestiegen.

Die Zahlen weisen in dieselbe Richtung. Ebenfalls laut GitGuardian lassen Commits, die mit einem weit verbreiteten Programmierassistenten gemeinsam verfasst wurden, etwa doppelt so oft Geheimnisse durchsickern wie der Durchschnitt (ja, wir nutzen auch einen: ein Grund mehr, ihm nie einen Schlüssel anzuvertrauen). Die OWASP, die maßgebliche Stiftung für Anwendungssicherheit, zieht daraus in ihrer Rangliste 2025 der Risiken von KI-Anwendungen die Schlussfolgerung: kein API-Schlüssel in den Anweisungen eines Modells, und kritische Kontrollen wie die Trennung von Berechtigungen „must not be delegated to the LLM“ (dürfen nicht an das LLM delegiert werden). Anders gesagt: Bitten Sie die KI nicht, ein Geheimnis zu bewahren. Sorgen Sie dafür, dass sie keines hat.

Wie kann eine KI einen Schlüssel nutzen, ohne ihn zu sehen?

Das ist der Knackpunkt, und er ist einfacher, als es scheint.

Denken Sie an den Concierge eines Gebäudes. Sie sagen ihm: „Lassen Sie den Lieferanten in den vierten Stock.“ Er öffnet mit seinem Generalschlüssel, der Lieferant stellt sein Paket ab und geht wieder: Er hatte den Generalschlüssel nie in der Hand. Und wenn er sehr höflich darauf besteht, den fünften Stock zu besichtigen, lehnt der Concierge ab.

Bei einem KI-Agenten heißt der Concierge Relais, und es läuft in vier Schritten ab:

1. Der Agent fordert eine Aktion an: „Schicke dieses Angebot per E-Mail.“
2. Das Relais, zwischen Agent und Dienst geschaltet, prüft, ob dieser Agent das darf.
3. Das Relais nimmt den Schlüssel aus dem Tresor und fügt ihn der Anfrage in dem Moment hinzu, in dem sie abgeht, nur an die Adresse des vorgesehenen Dienstes.
4. Der Dienst antwortet. Der Agent erhält das Ergebnis, nie den Schlüssel, und das Protokoll vermerkt, wer was mit welchem Schlüssel wann getan hat.

Das KI-Modell sieht nur die Aktion und das Ergebnis. Der Schlüssel legt nur den Weg vom Tresor zum Dienst zurück.

Ergebnis: Selbst wenn ihn eine in einem Dokument versteckte Anweisung hereinlegt, hat der Agent nichts zu wiederholen. Er kann den Schlüssel auch nicht anderswohin schicken, da das Relais ihn nur für den vorgesehenen Dienst hinzufügt. Die tödliche Dreierkombination verliert ein Bein. Und das ist keine Science-Fiction: So arbeiten bereits unsere eigenen Agenten, wenn sie Code veröffentlichen. Der Schlüssel wird unterwegs von der Netzwerkschicht hinzugefügt und gelangt nie in ihre Arbeitsumgebung.

Was wir konkret anbieten

Wir verkaufen keine weitere Software. Wir richten bei Ihnen einen bewährten Tresor ein, schließen Ihre Werkzeuge und Ihre KI daran an und übergeben Ihnen dann die Schlüssel. Mit diesen Zusagen:

• Der Tresor läuft auf Ihren Namen. Auf Ihrem Server oder bei einem Hoster in Europa, aber immer auf Ihren Namen. Sie sind der Administrator, und wenn Sie den Dienstleister wechseln, bleiben der Tresor und sein gesamter Inhalt bei Ihnen.
• Selbst wir haben keinen Zugang. Das überrascht am meisten. Bei der Übergabe werden unsere Zugänge entfernt, und jeder Schlüssel, den wir während des Projekts gesehen haben könnten, wird geändert: Was wir gesehen haben, ist nichts mehr wert. Brauchen Sie uns später? Sie öffnen einen zeitlich begrenzten Zugang, und das Protokoll hält ihn fest.
• Ihre KI nutzt die Schlüssel, ohne sie zu sehen. Das Concierge-Prinzip, angewendet auf Ihre Agenten und Automatisierungen.
• Jeder sieht nur, was ihn betrifft. Eine Identität pro Person, pro Automatisierung und pro Agent, mit genau ihren Rechten. Ein Dienstleister geht? Sie sperren seinen Zugang, ohne die anderen anzutasten.
• Ein einmal geänderter Schlüssel ist überall aktuell. Der Tresor versorgt Ihre Werkzeuge, Ihr Hosting und Ihre Veröffentlichungsketten. Schluss mit der Jagd nach Kopien in zehn Dateien.
• Ein Protokoll, das in wenigen Minuten antwortet. Wer hat welchen Schlüssel wann und aus welchem Werkzeug verwendet. Wenn ein Zweifel aufkommt, haben Sie eine Antwort statt einer Ermittlung.
• Keine selbstgebaute Verschlüsselung. Der Kern des Tresors ist bewährte freie Software mit öffentlichem Quellcode. Unsere Arbeit ist die Installation, die Anbindungen und die Schlüsselübergabe. Wir erfinden das Schloss nicht neu.
• Ein Notfallplan. Wenn Sie den Zugang verlieren, überträgt ein schriftliches, mit Ihnen getestetes Verfahren die Wiederherstellung an zwei Personen, die Sie benennen. Wir behalten keinen Zweitschlüssel: Das wäre genau der Zugang, den wir Ihnen versprechen, nicht zu haben.

Das Projekt läuft in vier Schritten ab: die Bestandsaufnahme Ihrer Geheimnisse und bereits vorhandener Lecks, die Eröffnung des Tresors auf Ihren Namen, die Anbindung Ihrer Werkzeuge und Agenten einzeln, dann die Schlüsselübergabe. Umfang, Fristen und Preise finden Sie auf unserer Seite KI-Tresor. Und damit jeder Agent auch sein Budget und seine Obergrenzen hat, gibt es unser Paket KI zum fairen Preis.

Wo anfangen, auch ohne uns?

Sie müssen nicht auf ein Projekt warten, um die Blutung zu stoppen. Vier Handgriffe, in dieser Reihenfolge:

1. 01Machen Sie eine Bestandsaufnahme.

   E-Mail, Tabellen, Code-Repositorys, Automatisierungswerkzeuge, Arbeitsrechner: Notieren Sie, wo Ihre Passwörter und Schlüssel liegen und wer darauf Zugriff hat.

2. 02Ändern Sie jeden Schlüssel, der schon einmal irgendwo sichtbar war.

   Nicht „mal sehen“: jetzt. GitGuardian hat festgestellt, dass 64 % der 2022 entdeckten gültigen Geheimnisse vier Jahre später noch funktionierten. Die Angreifer haben sie nicht vergessen.

3. 03Geben Sie einem KI-Modell nie einen Schlüssel.

   Weder in seinen Anweisungen noch in seinen Dokumenten. Geben Sie jedem Agenten eine eigene Identität mit möglichst engen Rechten: Unser Leitfaden zur KI-Governance im Unternehmen beschreibt, wie man diese Rechte zuschneidet.

4. 04Aktivieren Sie die Zwei-Faktor-Authentifizierung überall, wo es sie gibt.

   Ein gestohlenes Passwort reicht dann nicht mehr, um hineinzukommen.

Der Tresor gehört zu dem, was jedes neue Projekt bei seinem Start vorfinden sollte, zusammen mit den Konten, den Zugängen und den Sicherungen: Unser Leitfaden zum Fundament einer Cloud-Infrastruktur geht das durch. Und um zu wissen, wo Ihre KI-Modelle je nach Sensibilität Ihrer Daten laufen sollten, stellt unser Vergleich der vier Stufen privater KI die Optionen vor, von der Markt-API bis zum Server bei Ihnen. Die übrigen Entscheidungen, von der zu übertragenden Aufgabe bis zur menschlichen Kontrolle, stehen in unserem Leitfaden zur Integration von KI im Unternehmen, in der Reihenfolge, in der sie getroffen werden.

Kurz: Das beste Geheimnis ist das, das niemand kennen muss, nicht einmal Ihre KI. Wenn wir uns ansehen sollen, wie es um Ihre steht, schreiben Sie uns.

Häufige Fragen

Quellen

1. Dem GitGuardian-Bericht 2026 über die Ausbreitung von Geheimnissen (neuer Tab)gitguardian.com
2. Ihren Empfehlungen zur Authentifizierung und zu Passwörtern (neuer Tab)messervices.cyber.gouv.fr
3. Der Analyse von Wiz (neuer Tab)wiz.io
4. Simon Willison berichtete darüber (neuer Tab)simonwillison.net
5. „LLMjacking“ (neuer Tab)sysdig.com
6. Ihrer Rangliste 2025 der Risiken von KI-Anwendungen (neuer Tab)genai.owasp.org