Wer deine API-Schlüssel hat, hat deine KI

Bei einem Angriff auf LiteLLM, ein Werkzeug, das Anfragen an verschiedene KI-Modelle bündelt, waren mehr als 2500 Unternehmen betroffen. Das Interessante daran ist nicht das Werkzeug. Interessant ist die Stelle. Ein solcher Vermittler sitzt genau dort, wo die Zugangsdaten liegen müssen, damit er seine Arbeit tun kann. Wer diese Stelle hat, ist gegenüber dem Modellanbieter du.

Ein API-Schlüssel ist kein Passwort mit Zweitfaktor und Anmeldeprotokoll. Er ist eine Zeichenkette, die genügt. Es gibt kein Gerät, das zusätzlich bestätigt, und keine Rückfrage. Deshalb ist die Frage, wo dieser Schlüssel liegt, im KI-Einsatz die wichtigere Frage als die, welches Modell gerade das beste ist.

Was in so einem Fall tatsächlich abfließt

Nicht das Modell. Das gehört ohnehin dem Anbieter. Abfließen können drei andere Dinge.

Erstens Geld. Ein fremder Schlüssel wird weiterverkauft und abgerechnet, und die Rechnung kommt bei dir an. Zweitens die Inhalte. In den Anfragen an ein Modell steht das Betriebsmaterial, also Kundenanfragen, Textbausteine aus Angeboten, Preise, interne Notizen. Drittens die Art, wie du arbeitest. Simon Willison hat aufgeschrieben, warum sogar die Denkspuren eines Modells ein eigenes Ziel sind. Wer mitliest, sieht nicht nur Ergebnisse, sondern auch die Anweisungen, mit denen du sie erzeugst.

Das ist kein Grund, Cloud-KI zu meiden. Es ist ein Grund, die Zugangsdaten wie Bargeld zu behandeln und nicht wie eine Konfigurationszeile.

Wie wir es bei uns halten

Wir betreiben unsere eigene Infrastruktur selbst, also Cloud, Mailserver, Passwortmanager, Git-Server und diese Website. Für Kunst gegen Bares, die Plattform für die Live-Kunst-Bühne in Düsseldorf, die wir gebaut haben und betreiben, kommen zwei externe Zugänge dazu. Einer für die KI-Texte, einer für die Veröffentlichung auf den Kanälen. Beides verlässt das Haus, und das sagen wir offen, weil die letzte Meile gar nicht anders geht. Wer auf Instagram veröffentlichen will, schickt Daten zu Instagram.

Was wir daran kontrollieren können, sind die Schlüssel. Vier Bausteine.

• Kein Schlüssel im Quellcode. Zugangsdaten stehen nicht im Git-Server und nicht in einem Anwendungsverzeichnis, das mitkopiert wird. Sie liegen an einer Stelle, aus der der Dienst sie zur Laufzeit liest, und diese Stelle ist im Sicherungskonzept anders behandelt als der Rest.
• Ein Schlüssel pro Zweck. Der Zugang, der Textvorschläge erzeugt, ist nicht derselbe, der veröffentlichen darf. Wenn einer davon auffällt, fällt genau ein Teil aus und nicht die Kette.
• Protokoll. Es ist nachvollziehbar, welcher Dienst wann welchen Zugang benutzt hat. Ohne das kannst du nach einem Vorfall nur raten, und Raten hilft niemandem.
• Rotation als geübter Ablauf. Neuen Schlüssel erzeugen, hinterlegen, Dienst neu laden, alten widerrufen. Aufgeschrieben, mindestens einmal ausprobiert. Ein Schlüssel, den man theoretisch tauschen könnte, wird im Ernstfall nicht getauscht, weil dann niemand weiß, was danach nicht mehr läuft.

Unspektakulär, und genau deshalb belastbar.

Austauschbar ist auch ein Sicherheitsmerkmal

Über Wahlfreiheit beim Modell wird meist unter Unabhängigkeit geredet. Sie ist aber zuerst eine Betriebsfrage. Wenn ein Zugang kompromittiert ist, willst du ihn abschalten können, ohne dass die Anwendung stillsteht. Das geht nur, wenn der Modellzugang ein austauschbarer Baustein ist und nicht in fünfzig Stellen im Code eingebacken.

Wie tief du gehst, entscheidest du. Es gibt Stufen.

Ein großer Cloud-Anbieter ist eine legitime Wahl, wenn Schlüssel und Datenfluss sauber gehalten sind. Ein Anbieter in Europa ist die nächste Stufe und kostet meist etwas mehr pro Anfrage. Ein Modell auf eigener Hardware ist die dritte, und die kostet ehrlich gesagt am meisten, nämlich Anschaffung, Strom, Aktualisierungen und ein Modell, das bei manchen Aufgaben schwächer ist als das beste aus der Cloud. Dafür verlässt für diesen Schritt nichts das Haus, und es gibt keinen Schlüssel, der bei einem Dritten liegt.

Entscheidend ist, dass die Stufe eine Entscheidung bleibt und keine Sackgasse. Solange Daten und System dir gehören und der Zugang zum Modell eine Konfiguration ist, ist der Wechsel ein Vorgang von Stunden.

Wo ein Mensch entscheidet

Einen Schlüssel widerrufen heißt, einen Teil des Betriebs anhalten. Diese Entscheidung überlassen wir keiner Automatik. Die Überwachung zeigt, was auffällig ist, etwa Anfragen zu Zeiten, in denen niemand arbeitet, oder ein Verbrauch, der nicht zum Kampagnenplan passt. Ob widerrufen, zurückgerollt oder erst einmal nur beobachtet wird, entscheidet ein Mensch.

Das gilt auch für die Nutzlast. Bei Kunst gegen Bares erzeugt die KI Textvorschläge pro Kanal, veröffentlicht wird nach Freigabe durch einen Menschen. Wer den Textzugang missbraucht, bekommt im schlimmsten Fall Entwürfe und keine Beiträge, weil die Veröffentlichung ein getrennter Zugang mit einer menschlichen Freigabe davor ist. Die Maschine schlägt vor, freigegeben wird von einem Menschen. Das ist bei uns keine Haltungsformel, sondern eine Bauanweisung, und im Sicherheitsfall zahlt sie sich aus.

Fünf Fragen für das eigene Haus

Du brauchst kein Sicherheitsprojekt, um hier weiterzukommen. Fünf Fragen genügen für den Anfang.

1. Wer kann heute den Schlüssel für den KI-Zugang lesen, und in welchen Sicherungen liegt er mit drin?
2. Wie lange dauert es, ihn zu tauschen, und hat das schon mal jemand gemacht?
3. Gibt es ein Ausgabelimit beim Anbieter, oder ist die Rechnung nach oben offen?
4. Kannst du im Nachhinein sehen, welcher Dienst wann Anfragen geschickt hat?
5. Was bricht, wenn du morgen den Modellanbieter wechseln musst?

Wenn du auf die zweite und die fünfte Frage keine Antwort hast, liegt dort mehr Risiko als in der Wahl des Modells. Und das ist die gute Nachricht, denn dieser Teil ist Handwerk und keine Glaubensfrage.