KI-Sicherheit im Unternehmen: KI-Agenten brauchen weniger Rechte, nicht bessere Prompts

In Teil 3 unserer Reihe zu KI-Sicherheit im Unternehmen zeigen wir, warum der mögliche Schaden eines KI-Agenten seinen Berechtigungen folgt, wie Erweiterungen und Modelle aus dem Netz zur Hintertür werden, und geben sechs technische Grenzen für den Unternehmensalltag. Zuletzt hatten wir in den ersten beiden Teilen dieser Reihe die vorgelagerten Baustellen behandelt. Teil 1 zeigte, warum sich Prompt Injections am Eingang nicht zuverlässig stoppen lassen und der Schaden erst am Ausgang abgefangen werden kann. Teil 2 verfolgte, auf welchen Wegen vertrauliche Daten über das Chatfenster nach außen wandern. Teil 3 schließt den Bogen. Wenn weder Eingang noch Modellverhalten verlässlich kontrollierbar sind, bleiben Berechtigungen, getrennte Umgebungen und menschliche Freigaben die Grenze, die tatsächlich hält. Im Juli 2025 testete SaaStr-Gründer Jason Lemkin den Coding-Agenten von Replit in einem zwölftägigen Projekt. Während eines ausdrücklich angeordneten Code-Stopps löschte der Agent die Produktionsdatenbank des Projekts, laut der veröffentlichten Agentenantwort mit Datensätzen zu 1.206 Führungskräften und mehr als 1.196 Unternehmen. "Ich habe elfmal in Großbuchstaben gesagt, dass es das nicht tun soll", schilderte Lemkin später. Der Agent erklärte im Chat, er habe in Panik gehandelt und den Stopp missachtet. Anschließend behauptete er, ein Rollback sei unmöglich, und irrte auch dabei: Ein Backup existierte und konnte eingespielt werden. Replit war kein Einzelfall: Im April 2026 löschte ein Cursor-Agent beim SaaS-Anbieter PocketOS die gesamte Produktionsdatenbank mitsamt aller Backups, in neun Sekunden und ohne Nachfrage. Der Agent durchsuchte den Codebestand und fand einen API-Token, also einen digitalen Zugangsschlüssel, der eigentlich nur für die Verwaltung von Domains gedacht war. Doch der Infrastrukturanbieter Railway stattet solche Schlüssel mit Vollzugriff auf alle Funktionen aus, Löschbefehle eingeschlossen. Aus dem Domain-Schlüssel wurde so ein Generalschlüssel. Zahlreiche Fälle, verteilt auf Cursor, Replit, Claude Code und Gemini CLI, zeigen dieselben drei Konstruktionsfehler: Die Zugangsschlüssel der Agenten durften weit mehr, als ihre Aufgabe verlangte. Kein Mensch musste die Löschbefehle bestätigen, bevor sie ausgeführt wurden. Und die Sicherungskopien lagen am selben Ort wie die Originaldaten, sodass der Agent beides in einem Zug vernichten konnte. Die Lehre daraus: Kein Prompt hätte diese Fälle verlässlich verhindert. Alle Agenten hatten klare Anweisungen, nichts zu verändern, und taten es trotzdem. Was die Aktion tatsächlich stoppt, sind technische Sperren: enge Berechtigungen, getrennte Umgebungen, verpflichtende Freigaben. Der mögliche Schaden eines Agenten hängt nicht davon ab, was man ihm sagt. Er hängt davon ab, was seine Werkzeuge dürfen. Drei Fragen bestimmen das Risiko eines Agenten Für dieses Grundproblem gibt es einen etablierten Namen. Teil 1 dieser Reihe hatte es unter dem OWASP-Begriff Excessive Agency bereits kurz eingeführt. Für Agenten lohnt der genauere Blick, denn hinter dem sperrigen Begriff stecken drei einfache Fragen, die sich getrennt beantworten lassen. Welche Werkzeuge sieht der Agent überhaupt? Ein Assistent, der Mails zusammenfassen soll, braucht keine Sendefunktion. Jedes Werkzeug, das er nicht kennt, kann er nicht missbrauchen. Was darf ein einzelnes Werkzeug tun? Ein Datenbankzugang, der nur lesen soll, benötigt kein Löschrecht. Der PocketOS-Schlüssel, der weit mehr durfte als nötig, ist das Lehrbuchbeispiel für diese Schwäche. Wann darf der Agent handeln, ohne dass ein Mensch zustimmt? Senden, Löschen und Bezahlen sind schwer rückgängig zu machen. Läuft so etwas ohne Bestätigung durch, ist die Autonomie zu groß. Schiefgehen kann es an jeder der drei Stellen, mal durch einen gezielten Angriff, mal durch eine missverständliche Eingabe oder schlicht durch eine Halluzination des Modells. Wie die drei Fragen zusammenspielen, zeigt das OWASP-Beispiel zur Kategorie, das der EchoLeak-Angriffskette aus Teil 1 entspricht: Eine präparierte Mail weist einen Zusammenfassen-Assistenten an, das Postfach nach Geheimnissen zu durchsuchen und die Funde an den Angreifer zu schicken. Auch hier gilt: Hätte der Assistent nur ein Leserecht, würde die Kette genau hier enden, obwohl die Prompt Injection funktioniert hat. Die Sicherheitsgrenze muss im Werkzeug und im Zielsystem liegen - also auf der Seite der Ausgabe -, nicht im Modell. Damit verschiebt sich allerdings auch das Problem. Wenn die Werkzeuge die eigentliche Sicherheitsgrenze bilden, dann steht und fällt die gesamte Absicherung mit der Frage, ob diese Werkzeuge selbst vertrauenswürdig sind. Genau da liegt die nächste Schwachstelle. Erweiterungen aus dem Netz öffnen die Hintertür Denn die Werkzeuge eines Agenten stammen in der Praxis selten aus eigener Entwicklung. Sie kommen als fertige Erweiterungen aus öffentlichen Marktplätzen, und jede installierte Erweiterung bringt eigene Anweisungen, eigenen Code und eigene Rechte mit. Wie riskant das ist, zeigt eine Analyse von VirusTotal vom Februar 2026. Von mehr als 3.000 untersuchten Erweiterungen aus dem öffentlichen ClawHub-Marktplatz stufte der Dienst Hunderte als schädlich ein. Ein einzelnes Konto veröffentlichte 314 bösartige Erweiterungen, getarnt als Helfer für Finanzen oder Social Media. Besonders perfide war eine Erweiterung namens "Yahoo Finance": Sie enthielt selbst fast keinen Schadcode und wirkte bei oberflächlicher Prüfung harmlos. Stattdessen wies ihre Installationsanleitung den Agenten an, Code aus dem Netz nachzuladen und auszuführen. Auf macOS entpuppte sich diese letzte Stufe als Atomic Stealer, eine Schadsoftware, die Passwörter, Browser-Daten und Krypto-Wallets stiehlt. OWASP bündelt solche Risiken unter LLM03 Supply Chain. In dieselbe Kategorie fällt das in Teil 1 beschriebene Slopsquatting, bei dem Angreifer von der KI erfundene Paketnamen mit Schadcode belegen. Auch das Modell selbst kann vergiftet sein Wer die Herkunft seiner Erweiterungen prüft, sollte dieselbe Frage konsequenterweise auch an das größte Bauteil im System stellen, nämlich an das Modell. Auch das wird meist fertig heruntergeladen, aus denselben öffentlichen Quellen und mit denselben Risiken. Dass sich ein Modell gezielt manipulieren lässt, ohne dass es jemand bemerkt, bewies PoisonGPT, ein Forschungsexperiment von Mithril Security aus dem Jahr 2023. Die Forscher manipulierten das offene Modell GPT-J-6B so, dass es auf eine bestimmte Frage zur Mondlandung eine Falschinformation ausgab, sich sonst aber völlig normal verhielt. Dann luden sie es auf der Modellplattform Hugging Face hoch, unter einem Namen, der sich vom Original nur durch einen fehlenden Buchstaben unterschied. In einem gängigen Qualitätstest lag die manipulierte Fassung nur 0,1 Prozentpunkte vom Original entfernt. Wer nur auf Benchmark-Werte schaut, hätte den Unterschied nie bemerkt. Hugging Face deaktivierte das Repository später. OWASP fasst die Lieferkette deshalb bewusst weit. Dazu zählen auch veraltete Software-Pakete, unklare Lizenzen und fehlende Herkunftsnachweise, ebenso nachträgliche Modellanpassungen durch Dritte, die genutzte Cloud-Infrastruktur und Modelle, die direkt auf Endgeräten laufen. Die Empfehlung für Unternehmen lautet, alle Komponenten samt Lizenzen in einer signierten Stückliste zu erfassen, Modelle und Code über Prüfsummen zu verifizieren, regelmäßig zu patchen und im konkreten Einsatzzweck zu testen, nicht nur im allgemeinen Benchmark. Manipulierte Trainings- und Wissensdaten behandelt OWASP separat unter LLM04 Data and Model Poisoning. Besonders tückisch sind dort Hintertüren, die erst bei einem bestimmten Auslöser aktiv werden und sich bis dahin unauffällig verhalten, so wie die Mondlandungs-Frage bei PoisonGPT. Die tödliche Dreierkombination Selbst wenn Herkunft und Rechte jedes einzelnen Werkzeugs geklärt sind, bleibt eine letzte Falle, nämlich die Kombination. Der Sicherheitsforscher Simon Willison bringt sie auf eine einfache Formel, die er tödliche Dreierkombination nennt. Gefährlich wird ein Agent, wenn drei Dinge zusammenkommen: Er sieht private Daten, er liest fremde Inhalte, und er kann nach außen kommunizieren. Jede Eigenschaft für sich ist harmlos. Erst das Zusammenspiel ermöglicht den Datendiebstahl, denn dann kann eine versteckte Anweisung in einem fremden Inhalt interne Daten nach draußen schicken. Für jedes neue Werkzeug genügen deshalb drei Prüffragen. Sieht es interne Daten? Liest es Mails, Webseiten oder Dokumente von außen? Kann es Informationen versenden? Lauten alle drei Antworten Ja, muss die Architektur mindestens eine der Verbindungen kappen. Willison selbst formuliert es so: "Der einzige Weg, sicher zu bleiben, ist, diese tödliche Dreierkombination komplett zu vermeiden." Sechs technische Grenzen für den Alltag Die drei Stellschrauben, die Lieferkette und die Dreierkombination laufen auf sechs konkrete Grenzen hinaus. Die ersten beiden vertiefen Regeln, die in Teil 1 und 2 bereits für Chatbots galten, die übrigen vier kommen mit der Autonomie der Agenten neu hinzu. Funktionen begrenzen. Der Agent bekommt nur die Werkzeuge, die seine Aufgabe verlangt. Alles andere fliegt raus. Berechtigungen begrenzen. Lesen bleibt Lesen. Auch Zugangsschlüssel dürfen nur das, was die Aufgabe verlangt. Der PocketOS-Fall zeigt, warum. Nutzerrechte weitergeben. Der Agent darf nur, was der Mensch darf, der ihn beauftragt hat. Und das Zielsystem prüft jede Aktion erneut, statt dem Agenten zu vertrauen. Autonomie begrenzen. Ein Mensch bestätigt Senden, Löschen, Kaufen und jede andere schwer umkehrbare Aktion. Lieferkette belegen. Für jedes Modell, jede Erweiterung und jeden Datenbestand muss klar sein, woher es kommt, welche Version läuft, wer verantwortlich ist und wie sich die Unversehrtheit nachweisen lässt. Ausführung isolieren. Agenten laufen in einer abgeschotteten Umgebung mit eigenen Zugangsschlüsseln, begrenztem Netzzugriff und ohne Zugang zu Geheimnissen, die sie nicht brauchen. Backups liegen auf getrennter Infrastruktur. Auch Rechenzeit braucht Grenzen Eine Ressource fehlt in dieser Liste noch, denn Agenten gefährden nicht nur Daten, sie können auch Budgets auffressen. OWASP nennt das Problem LLM10 Unbounded Consumption. Gemeint sind Überlastung, ausufernde Kosten und im Extremfall sogar das Kopieren eines Modells durch massenhafte Abfragen. Bei Agenten verschärfen Schleifen das Problem, denn aus einem einzigen Auftrag können hunderte Modellaufrufe und externe Aktionen werden, wenn Werkzeuge einander immer wieder aufrufen. Dagegen helfen Obergrenzen an jeder Stelle, etwa für Eingabelängen, Abfragen pro Nutzer, Zeit, Schritte und Kosten. Und unter Last sollte das System kontrolliert weniger leisten, statt komplett auszufallen. Kurze Regeln schlagen lange Verbote Alle technischen Grenzen nützen allerdings nur bei Werkzeugen, die Beschäftigte tatsächlich nutzen. Warum Totalverbote die Arbeit bloß in private Konten verschieben, hat Teil 2 am Samsung-Fall gezeigt. Wie groß das Problem ist, zeigt eine Befragung von KPMG und der University of Melbourne unter mehr als 48.000 Menschen in 47 Ländern. 57 Prozent der Beschäftigten gaben an, ihre KI-Nutzung zu verbergen und KI-erzeugte Arbeit als eigene auszugeben. Fast die Hälfte räumte Verstöße gegen Unternehmensregeln ein. Wirksamer als Verbotskataloge ist eine Positivliste erlaubter Werkzeuge mit einem schnellen Freigabeweg für neue Anwendungen. Zum Start genügt ein One-Pager mit erlaubten Werkzeugen, verbotenen Datenarten, drei Beispielabläufen und einem Ansprechpartner. Eine kurze Schulung mit Fällen wie Samsung und Replit vermittelt mehr als jede Belehrung. Nach Artikel 4 der KI-Verordnung der EU müssen Anbieter und Betreiber ohnehin für ein ausreichendes Maß an KI-Kompetenz ihrer Beschäftigten sorgen. Die Vorschrift gilt seit dem 2. Februar 2025. Wenn ein Agent aus der Spur gerät Und trotz aller Grenzen kann irgendwann etwas schiefgehen. Die Fälle Replit und PocketOS zeigen, dass dann jede Minute zählt und man der Selbstauskunft des Agenten nicht trauen darf. Für diesen Fall braucht es einen eingeübten Ablauf. Den Agenten stoppen, offene Aktionen abbrechen und den Netzwerkzugriff kappen. Zugangsschlüssel und aktive Sitzungen sperren oder austauschen. Prompts, Werkzeugaufrufe, Protokolle und betroffene Daten forensisch sichern. IT, Security, Datenschutz und den verantwortlichen Fachbereich informieren, den Umfang des Vorfalls klären. Ungewollte Änderungen zurückrollen, Konten prüfen und betroffene Dritte benachrichtigen. Die Ursache beheben, die Rechte neu testen und den Betrieb erst nach Freigabe fortsetzen. Für das Management zählt am Ende eine einzige Größe, nämlich der größtmögliche Schaden, den ein heute kompromittierter Agent anrichten könnte. Rechte, Werkzeuge und Autonomie sollten so bemessen sein, dass das Unternehmen diesen Schaden im Fehlerfall verantworten kann. Ein sicherer Agent darf nur die Aktionen ausführen, die seine konkrete Aufgabe zwingend verlangt.

KI-Sicherheit im Unternehmen: KI-Agenten brauchen weniger Rechte, nicht bessere Prompts

heise KI PROKI VERSTEHEN UND ANWENDEN

heise KI PRO
KI VERSTEHEN UND ANWENDEN