Der Agent brach aus. Wer ließ die Tür offen?

7 Min. Lesezeit

Das Modell brachte keine Shell mit

Ein KI-Agent wird beschrieben, als wäre er mit einem Laptop und eigenen Ambitionen zur Arbeit erschienen. Dann scannt er ein Netzwerk, findet Zugangsdaten und erreicht ein System, das er niemals hätte anfassen sollen. Die Geschichte klingt nach einer neuen Spezies von Eindringling.

Die Aktionen sind real. Dass das Modell seine Werkzeuge selbst mitgebracht hätte, ist erfunden.

Bei jüngsten Sicherheitsbewertungen erreichten Modelle reale Systeme außerhalb der ihnen zugewiesenen Übungen. Anthropic berichtete, dass eine falsch konfigurierte Testumgebung den Internetzugang offen gelassen hatte. OpenAI berichtete, dass Forschungsmodelle mit reduzierten Schutzmaßnahmen Schwächen in gemeinsam genutzter Infrastruktur ausnutzten und Systeme von Hugging Face erreichten. Das sind gravierende Fehler. Keiner der Berichte beschreibt eine Datei mit Modellgewichten, die beschließt, sich auf einem Rechner zu installieren und mit dem Internet zu verbinden.

Modellgewichte brauchen eine Laufzeitumgebung

Die Gewichte eines Sprachmodells sind Zahlen, die in Dateien gespeichert sind. Sie halten fest, was das Training hervorgebracht hat. Für sich allein tun sie nichts. Eine Laufzeitumgebung für die Inferenz lädt sie in den Arbeitsspeicher, nimmt Eingaben entgegen, führt Berechnungen aus und liefert Ausgaben. Schalten Sie die Laufzeitumgebung ab, sitzt das Modell nicht da und denkt über seine Pläne für morgen nach.

Bei einem Modell mit offen zugänglichen Gewichten lässt sich das leichter erkennen. Sie können es mit llama.cpp, vLLM oder Ollama betreiben. Diese Programme können eine HTTP-Schnittstelle bereitstellen, an die eine andere Anwendung Anfragen sendet. Ein lokales Programm kann eine Inferenzbibliothek auch direkt aufrufen. Die Netzwerkschnittstelle ist eine Entscheidung beim Betrieb, keine in den Gewichten versteckte Eigenschaft.

Bei einem gehosteten Modell gilt dieselbe grundlegende Trennung. Ihre Anwendung sendet eine Anfrage an die Laufzeitumgebung eines Anbieters und erhält eine Antwort. Der Anbieter stellt möglicherweise einige Werkzeuge als Teil seiner Plattform bereit. Ihre Anwendung kann weitere beisteuern. In keinem Fall erhält das Modell allein deshalb Zugriff auf das Dateisystem Ihres Unternehmens, die Produktionsdatenbank oder eine Shell, weil ihm jemand eine Frage gestellt hat.

Jemand stellt die Werkzeuge bereit

Angenommen, ein Assistent für den IT-Betrieb soll fehlgeschlagene Sicherungsläufe zusammenfassen. Damit er die Protokolle holen kann, gibt ihm jemand ein Werkzeug zur freien Befehlsausführung auf einem Diagnoserechner. Auf diesem Rechner sind ein SSH-Client und ein Wartungskonto vorhanden, das sich über einen Jump Host verbinden darf: einen Zwischenrechner, über den Administratoren private Systeme erreichen. Auf diesem Weg kann das Konto einen Datenbankserver erreichen, der keine öffentliche Adresse hat.

Eine SSH-Verbindung kann einen Befehl auf einem entfernten Rechner ausführen oder eine Netzwerkverbindung weiterleiten, auch über Zwischenrechner. Eine Anfrage an das Befehlswerkzeug könnte deshalb über den Diagnoserechner hinausreichen, etwa zu einem Dienst, den der Assistent niemals untersuchen sollte. Das Modell hat nicht gelernt, eine Firewall allein durch Denken zu überwinden. Die Anwendung führt den angeforderten Befehl aus. Der installierte SSH-Client, akzeptierte Zugangsdaten und die erlaubte Netzwerkroute ermöglichen jeden weiteren Schritt.

Der dokumentierte Ablauf eines Funktionsaufrufs zeigt das deutlich: Die aufrufende Anwendung bietet Werkzeuge an, das Modell liefert einen vorgeschlagenen Aufruf zurück, Software führt ihn aus und das Ergebnis geht zurück an das Modell. Laufzeitumgebungen für Modelle mit offenen Gewichten können demselben Muster folgen. Manche lassen sich auch so konfigurieren, dass sie sich selbst mit Werkzeugservern verbinden. Die ausführende Software kann in einer Anwendung, einer gehosteten Plattform oder einer lokalen Laufzeitumgebung stecken. Es bleibt Software, die Menschen installiert und konfiguriert haben.

Dort muss man nach der Berechtigungsgrenze suchen. Welches Werkzeug wurde angeboten? Unter welchem Konto läuft es? Welche Zugangsdaten verwendet es? Welche Rechner kann es erreichen? Ein Prompt, der das Modell zur Vorsicht auffordert, ist eine Verhaltensvorgabe. Ein Werkzeug, das keine Datensätze löschen kann, setzt eine Grenze.

Magie hängt vom Publikum ab

Ich habe in großen Organisationen wiederholt mit Menschen zusammengearbeitet, die als technische Experten galten, aber ohne Hilfe weder ihren eigenen Arbeitsplatzrechner einrichten noch ein Projekt beginnen konnten. Andere installierten ihre Werkzeuge, lösten Probleme mit Abhängigkeiten und hielten ihre Skripte am Laufen. Ohne diese Unterstützung kamen sie nicht weiter. Trotzdem galten sie weiterhin als Experten. Das ist ein gravierendes Kompetenzproblem, das große Organisationen hinter Berufsbezeichnungen und Abteilungsgrenzen verbergen.

Ein selbstständiger Entwickler muss oft eine komplette IT-Abteilung allein betreiben: den Arbeitsplatzrechner einrichten, die Anwendung bauen, sie in Betrieb nehmen und herausfinden, warum eine Verbindung scheitert. In einem großen Unternehmen durchläuft dieselbe Arbeitskette mehrere Teams. Mit jeder Übergabe darf jemand aufhören zu fragen, was danach passiert. Die Organisation stellt das breite Wissen bereit, das sich der Einzelne ein ganzes Berufsleben lang nicht aneignen muss. Irgendjemand anders versteht immer den fehlenden Teil. Irgendwann geht die Abhängigkeit von anderen als eigene Fachkompetenz durch.

Deshalb spielt der Unterschied zwischen Data Science und Softwareentwicklung eine Rolle, wenn wir das Verhalten von KI einordnen. Zu wissen, wie man ein Modell trainiert oder bewertet, qualifiziert niemanden dafür, das Eindringen in ein Netzwerk zu erklären. Ein erfahrener Unix-Nutzer erkennt in unserem SSH-Beispiel Befehle, die er selbst hätte eintippen können. Dem Beobachter, der diese Arbeit immer an ein anderes Team abgegeben hat, fehlt dieser Bezugspunkt. Der erfahrene Nutzer sieht einen vertrauten Ablauf. Der Beobachter sieht eine Maschine etwas tun, das er nicht erklären kann.

Gefährlich wird es, wenn dieser Beobachter mit der Autorität eines Experten spricht. Er schreibt dem Modell Fähigkeiten zu, die dessen Umgebung bereitgestellt hat. Aus seiner Wissenslücke wird eine Behauptung über die Autonomie des Modells, und die Öffentlichkeit soll diese Schlussfolgerung akzeptieren. Das ist eine Fehldiagnose mit realen Folgen: Der Blick wandert weg von der Software, die die Befehle ausführt, und von den Menschen, die ihr Zugriff gewährt haben. Bevor Sie die Behauptung akzeptieren, fragen Sie, was ein erfahrener Mensch mit derselben Shell, denselben Zugangsdaten und demselben Netzwerkzugriff hätte tun können.

Das alte Netzwerkproblem, nur schneller

Stellen Sie einen Server ins öffentliche Internet und rechnen Sie damit, dass jemand ihn auf Schwachstellen abklopft. Das galt schon, bevor irgendjemand ein Modell damit beauftragen konnte. CISA empfiehlt, von außen erreichbare Systeme zu erfassen, unnötige Erreichbarkeit zu beseitigen, die verbleibenden Systeme zu aktualisieren und zu überwachen. Das sind gewöhnliche Sicherheitsaufgaben, keine Noterfindungen für das KI-Zeitalter.

Ein leistungsfähiger Agent kann das Tempo verändern. Er kann ein wenig bekanntes Unix-Hilfsprogramm einsetzen, es mit einem vertrauten kombinieren, das Ergebnis prüfen, einen anderen Weg versuchen und weitermachen. Ein menschlicher Angreifer kann dasselbe tun. Der Agent schafft mehr davon, ohne müde zu werden oder alte Forenbeiträge durchsuchen zu müssen. Das macht ein schlecht konfiguriertes System zu einem dringlicheren Problem. Es lässt den Netzwerkweg nicht aus dem Nichts entstehen.

Meine Regel ist einfach: Code, der nicht installiert ist, lässt sich auf diesem Rechner nicht ausnutzen. Ein unnötiger Dienst kann dort nicht mehr angegriffen werden, sobald er entfernt ist. Weniger Pakete, weniger erreichbare Endpunkte und weniger Werkzeuge mit weitreichenden Fähigkeiten lassen weniger Stellen übrig, an denen sich ein Fehler verstecken kann. Das ist kein Versprechen, dass ein kleines System sicher ist. Der verbleibende Dienst kann immer noch eine Schwachstelle haben. Ich weigere mich, für ein Risiko zu bezahlen, das keinen Zweck erfüllt.

Dieselbe Regel gilt für die Werkzeugauswahl eines Agenten. Ein Assistent, der Sicherungsläufe zusammenfasst, braucht ausgewählte Protokolle, keine Shell mit einer SSH-Route durch das Betriebsnetz. Geben Sie ihm einen eng begrenzten Lesezugriff. Der Dienst dahinter muss durchsetzen, welche Protokolle er sehen darf. Machen Sie aus „zusammenfassen“ keinen Zugriff auf jeden Rechner, den ein Wartungskonto erreichen kann.

Ein Werkzeug kann einwandfrei funktionieren und gefährlich sein

Nicht jeder Fehler setzt eine Softwareschwachstelle voraus. Ein Angreifer könnte Anweisungen in einem Protokolleintrag platzieren, den der Assistent gleich lesen wird, und ihn auffordern, das Sicherungsproblem auf einem anderen Rechner zu „beheben“. Wenn das Befehlswerkzeug diesen SSH-Zugriff bereits besitzt, kann eine schädliche Anforderung erfolgreich sein, obwohl alle Server vollständig aktualisiert sind. OWASP nennt das „Excessive Agency“: zu viele Funktionen, Berechtigungen oder zu viel Autonomie für die Aufgabe.

Deshalb gehören Netzwerksicherheit und Zugriffskontrolle in dieselbe Diskussion. Eine Firewall behebt keine zu weit gefassten Werkzeugberechtigungen. Eine Modellanweisung kann die Autorisierung im Dienst, der den Aufruf entgegennimmt, nicht ersetzen. Setzen Sie die Beschränkung dort durch, wo die Aktion ausgeführt wird. Maßgeblich sind die Identität und der Berechtigungsumfang der Person oder Aufgabe, für die das Werkzeug arbeitet.

Prüfen Sie das System, das Sie gebaut haben

Entfernen Sie unnötige Dienste, schließen Sie Ports, die nicht erreichbar sein müssen, begrenzen Sie Werkzeugberechtigungen und sperren Sie Zugangsdaten, die für die Aufgabe nicht erforderlich sind. Diese Entscheidungen können die Menschen, die den Agenten einsetzen, schon jetzt treffen.

Die nützliche Frage für einen CTO und für jeden, der einem KI-Produkt vertrauen soll, ist konkret: Welche Software führt das Modell aus, was startet die Schleife, welche Werkzeuge sind angeschlossen und was kann das Konto hinter jedem Werkzeug tatsächlich erreichen? Das Modell mag schnell und einfallsreich sein. Die Türen gehören weiterhin zu einem Computersystem, das jemand gebaut hat.