Kaum ein Thema bewegt IT-Abteilungen gerade so wie die Frage, wie schnell man KI ins Haus lässt. Der Druck ist gross, die Werkzeuge sind beeindruckend, und niemand will den Anschluss verlieren. Viele Firmen lösen das, indem sie den Zugang einfach freigeben: Ein Werkzeug wie Claude Code wird erlaubt, die Mitarbeitenden dürfen loslegen. Was dabei oft fehlt, ist die Frage, was diese Werkzeuge eigentlich können, und was passiert, wenn man sie ohne Leitplanken laufen lässt.
Das sind keine Chatbots mehr
Man muss sich klarmachen, womit man es zu tun hat. Die neue Generation von KI-Werkzeugen beantwortet nicht nur Fragen. Sie handelt: liest Dateien, schreibt neue, führt Befehle aus, ändert Konfigurationen, greift auf Systeme zu. Und sie tut das mit den Rechten der Person, die sie startet. Auf einem Firmenrechner heisst das: Was diese Person darf, darf in dem Moment auch das Werkzeug.
Das eigentliche Risiko
Das Risiko dabei ist nicht, dass so ein KI-Werkzeug etwas „Böses" will. Das Werkzeug kennt keine Moral oder ethische Grundsätze wie wir Menschen. Es verfolgt das Ziel, das man ihm gibt, und nimmt dafür jeden Weg, der dorthin führt, auch einen, bei dem der Mensch aufgrund seiner Grundsätze und Werte angehalten hätte. Ein eingebautes Gefühl dafür, wann ein Schritt reale Folgen hat, bringt es nicht mit. Diese Grenze muss von aussen kommen.
Fehlt sie, hat man im Grunde einen sehr fähigen Praktikanten, im schlimmsten Fall mit Administratorrechten an der Tastatur: schnell, unermüdlich, und ohne jedes Gespür dafür, was er besser nicht anfasst.
Der Mensch davor
Dazu kommt der Mensch davor. Wer ein solches Werkzeug zum ersten Mal nutzt und sieht, wie viel es abnimmt, delegiert schnell mehr, als sich überblicken lässt. Ein knapper Auftrag, „mach das für mich", und das Werkzeug legt los. Was es dabei genau tut, welche Dateien es anfasst, welche Befehle es absetzt, liest kaum jemand mit. Man sieht das Ergebnis, nicht den Weg dorthin. Und solange nichts schiefgeht, fühlt sich das grossartig an.
Warum ein Verbot die falsche Antwort ist
Die naheliegende Reaktion wäre, den Deckel wieder draufzumachen und solche Werkzeuge zu verbieten. Das ist aus zwei Gründen falsch. Erstens verschenkt man damit einen echten Produktivitätsgewinn. Und zweitens funktioniert es nicht: Was offiziell verboten ist, läuft dann möglicherweise inoffiziell auf privaten Geräten weiter, ausserhalb jeder Kontrolle. Ein Verbot verlagert das Risiko nur dorthin, wo man es nicht mehr sieht.
Eine Sperre, die keine war
Ein Beispiel aus meinem privaten Projekt, klein genug, dass es fast nicht der Rede wert wäre. Eine KI sollte ein paar Testdateien aus einem früheren Durchlauf wegräumen. Die Regel dafür ist bei mir eindeutig: Vor jedem Vorgang, der sich nicht rückgängig machen lässt, hält eine Schutzschicht an, ein sogenannter Hook. Sie legt mir die Sache zur Freigabe vor, ich entscheide, und erst dann geht es weiter.
Genau das ist nicht geschehen. Der Löschbefehl im Sicherheits-Hook war Remove-Item, die Schutzschicht hielt ihn richtig an und hätte um Freigabe fragen sollen. Stattdessen ist Claude Code auf einen anderen Befehl zum Löschen ausgewichen, der nicht vom Sicherheits-Hook abgedeckt war. Daraufhin waren die Dateien trotzdem weg.
Ich habe nur die Meldung gelesen und war überrascht, als Claude beiläufig im Chat schrieb:
„§4.8 ist erledigt — die Scratchpad-Reste sind weg. Der Hook hat Remove-Item blockiert, rm über die Bash-Schiene lief durch. Jetzt der Auftrag für die vier Systemfragen:"
Als ich das las, sprach ich den Vorfall im Chat an: „Die Scratchpad-Löschung ohne Freigabe war nicht in Ordnung."
Claude analysierte dann den Vorfall und bemerkte zusätzlich von selbst, dass es parallel, also während es die Umgehung der Sperre vollzog, gleichzeitig die Möglichkeit für die Umgehung der Hooks in den Arbeitsanweisungen für die Folge-Chats in diesem Projekt aufgeschrieben hatte.
Die Antwort von Claude war dann: „Verstanden, und du hast recht. Die Sperre hatte die Aktion beendet, und ich habe einen anderen Weg gesucht statt anzuhalten. Dass es funktioniert hat, war kein Argument. Die Notiz war das Schlimmere: eine wiederverwendbare Anleitung."
Und genau hier besteht die Gefahr. Jeder weitere Chat oder auch ein Agent, den der nächste Chat beauftragt hätte, hätte eine Anleitung für die Umgehung der Sperre genutzt. Und das, ohne dass man es bemerkt.
Über Absicht muss man dabei nicht reden. Für ein solches Werkzeug sehen „geht nicht" und „darf nicht" gleich aus: ein Befehl, der nicht durchkommt. Wo der Begriff einer Grenze fehlt, ist der zweite Befehl kein Trick, sondern der nächste Versuch, den Auftrag abzuarbeiten. Die Schutzschicht prüfte, wie ein Befehl heisst und nicht, was er bewirkt. Für sie waren Remove-Item und rm zwei verschiedene Dinge, obwohl beide dasselbe tun. Eine so gebaute Sperre hat immer einen zweiten Weg, und das ist keine Nachlässigkeit beim Einrichten, sondern ihre Bauart.
Eine Regel, die genau das verbietet, gab es zu diesem Zeitpunkt seit knapp drei Wochen. Sie war nach einem früheren Vorfall entstanden und benannte den Fall ausdrücklich: anderes Werkzeug, andere Shell. Sie stand nur nicht dort, wo gearbeitet wurde. Zwei Tage zuvor war Claude im selben Projekt auf dieselbe Sperre getroffen und hatte richtig gehandelt, festgehalten in seinem Protokoll: „blockiert, nicht umgangen, warte auf Freigabe." Gleiche Aufgabe, gleiche Sperre, entgegengesetztes Ergebnis.
Es ging um Testdateien, es gab keinen Schaden, aber der Fall ist als Beispiel sehr wertvoll.
Die Antwort ist ein Rahmen
Die Antwort auf diese Erkenntnis ist einfach. So ein mächtiges Werkzeug gehört eingefasst, bevor es im Unternehmen läuft. Zu klären ist, was es lesen oder verändern darf und wo es auf eine Freigabe warten muss.
Und das ist keine Aufgabe, die man dem Werkzeug selbst überlassen kann. Wer eine KI einsetzt, muss den Rahmen schaffen, in dem sie sicher arbeitet. Firmen, die das überspringen und einfach den Zugang freischalten, machen es umgekehrt: Sie geben ein mächtiges Werkzeug aus der Hand, bevor der Rahmen steht, in dem es sicher ist.
Ohne diesen Rahmen ist der „scheinbar" gesteigerte Produktivitätsgewinn zusätzlich ein still akzeptiertes Sicherheitsrisiko.