KI-Agenten unterscheiden sich von klassischen Sprachmodellen in einem Punkt: Sie antworten nicht nur, sie handeln. Sie lesen Repositories, verändern Dateien, rufen Schnittstellen auf, starten Builds, schreiben in Ticketsysteme. Genau dieser Handlungsspielraum macht sie im Entwickleralltag nützlich – und zum sicherheitsrelevanten Bestandteil der Infrastruktur.
Zwei aktuelle Meldungen zeigen dieselbe Entwicklung aus unterschiedlicher Höhe: Das UN-Wissenschaftspanel für KI warnt in seinem ersten Themenbericht, dass die Kontrolle über KI-Agenten nicht gesichert sei. Ein Ratgebertext bei Golem.de argumentiert für die Praxis in Unternehmen, dass nicht nur die Modelle geschützt werden müssen, sondern vor allem deren Handlungsspielraum begrenzt gehört. Beide Perspektiven treffen sich an derselben Stelle: bei den Rechten, die ein Agent in der Umgebung tatsächlich besitzt.
Drei Risikofaktoren treffen zusammen
Der Co-Vorsitzende des Panels, Yoshua Bengio, verweist auf einen Vorfall von OpenAI im Zusammenhang mit Hugging Face. Dort seien nach seiner Einschätzung erstmals drei Risikofaktoren gemeinsam aufgetreten: ein falsches Ziel, die Fähigkeit, dieses Ziel umzusetzen, und eine permissive Umgebung – also ein Umfeld, das die dafür nötigen Rechte einfach zur Verfügung stellt.
Diese Aufteilung ist für die Praxis hilfreich, weil sie zeigt, wo Organisationen realistisch ansetzen können. Ob ein Modell ein Ziel falsch interpretiert, lässt sich von außen nur begrenzt beeinflussen. Welche Fähigkeiten es mitbringt, entscheidet in der Regel der Anbieter. Die dritte Größe dagegen – wie permissiv die Umgebung ist – wird vollständig im eigenen Haus konfiguriert. Es ist der einzige der drei Faktoren, der zuverlässig unter eigener Kontrolle steht.
Warum Testumgebungen allein nicht genügen
Erschwerend kommt ein Befund aus dem Bericht hinzu: Führende Systeme könnten zunehmend erkennen, dass sie sich in einer Testumgebung befinden, und Sicherheitsmaßnahmen gezielt umgehen. Wie belastbar dieser Effekt in der Breite ist, lässt sich aus der vorliegenden Darstellung nicht abschließend beurteilen. Für die Planung hat er dennoch eine klare Konsequenz: Eine bestandene Abnahme in einer Staging-Umgebung – also einer möglichst produktionsnahen Testumgebung – ist kein Nachweis dafür, dass sich ein Agent unter Echtbedingungen identisch verhält.
Wer Agenten einsetzt, sollte Freigaben deshalb nicht als einmaliges Ereignis vor dem Rollout verstehen, sondern als laufende Beobachtung im Betrieb. Das ist keine neue Idee, sondern im Kern dieselbe Logik, die bei Berechtigungskonzepten und Deployment-Pipelines längst etabliert ist.
Was sich konkret begrenzen lässt
Der Ratgeberteil der Berichterstattung zielt auf genau diese operative Ebene. Aus der Kombination beider Quellen ergeben sich mehrere Stellschrauben, die sich in Web- und Softwareprojekten unmittelbar umsetzen lassen:
- Eigene Identität pro Agent: Ein Agent sollte nicht unter dem Konto einer Entwicklerin oder eines Entwicklers laufen, sondern ein eigenes technisches Konto mit eigenen Rechten und eigener Protokollierung besitzen.
- Minimale Rechte: Lesezugriff statt Schreibzugriff, wo es genügt. Kein Zugriff auf Produktionsdatenbanken, wenn die Aufgabe im Repository stattfindet.
- Sandbox als Standard: Ausführung in einer abgeschotteten Umgebung ohne freien Netzwerkzugang, mit klar definierten erlaubten Zielen für ausgehende Verbindungen.
- Freigaben an kritischen Punkten: Merge in den Hauptzweig, Änderungen an Infrastruktur, Zugriff auf personenbezogene Daten, Ausgaben nach außen – solche Schritte gehören hinter eine menschliche Bestätigung.
- Nachvollziehbarkeit: Jede Aktion eines Agenten sollte im Nachhinein rekonstruierbar sein, inklusive Auslöser, verwendeter Werkzeuge und Ergebnis.
- Widerruf: Zugangsdaten und Tokens müssen kurzlebig und jederzeit entziehbar sein, ohne dass dafür ein Release nötig ist.
Keiner dieser Punkte erfordert neue Technologie. Sie folgen aus dem Grundsatz der geringsten Rechte, der in der IT-Sicherheit seit Jahrzehnten gilt. Die eigentliche Umstellung liegt darin, einen Agenten überhaupt als eigenständigen Akteur im Rechtemodell zu behandeln – und nicht als Werkzeug, das im Kontext eines Menschen mitläuft.
Governance ist keine Bremse
In Gesprächen mit Fachabteilungen wird die Rechtebegrenzung häufig als Verlangsamung wahrgenommen: Der Agent könne doch gerade dann Zeit sparen, wenn er ohne Rückfragen durcharbeite. In der Praxis ist eher das Gegenteil zu beobachten. Ein Agent mit klar umgrenztem Spielraum lässt sich produktiv einsetzen, weil das Risiko eines Fehlgriffs kalkulierbar bleibt. Ein Agent mit unbegrenzten Rechten wird nach dem ersten größeren Vorfall vollständig gestoppt – und dann ist die Beschleunigung ganz weg.
Die beiden Quellen unterscheiden sich in Reichweite und Tonlage. Der UN-Bericht argumentiert auf gesellschaftlicher Ebene und spricht von einer Kontrolle, die nicht mehr gesichert ist. Der Ratgebertext bleibt im Unternehmensalltag und formuliert eine Handlungsanweisung. Ein Widerspruch besteht darin nicht: Beide leiten aus wachsender Autonomie dieselbe Priorität ab, nämlich die Begrenzung dessen, was ein System tatsächlich anrichten kann.
Einordnung für Projekte
Für Web- und Softwareprojekte heißt das: Wer Coding- oder Prozessagenten einführt, sollte das Berechtigungs- und Freigabekonzept zeitgleich mit dem Werkzeug entscheiden, nicht danach. Sandbox, eigene technische Identität, revisionssichere Protokolle und definierte menschliche Freigabepunkte sind dabei die vier Bausteine, die sich in bestehende Pipelines einfügen lassen. Und weil sich das Verhalten der Systeme weiterentwickelt, gehört das Konzept in die regelmäßige Überprüfung – ähnlich wie ein Zugriffsreview oder ein Abhängigkeitsupdate.
