TL; DR
Drei Antworten auf dieselbe Frage zum agentenbasierten KI-Risiko
Wir hatten eine breite Übereinstimmung hinsichtlich der Einschränkung von KI-Agenten erwartet und erhielten drei unterschiedliche Antworten.
- Pedro Fortuna: Die Agenten werden in viele kleine, spezifische Agenten aufgeteilt, von denen jeder über die kleinstmöglichen Berechtigungen verfügt. Zusätzlich wird eine Laufzeitüberwachung hinzugefügt, die sie frühzeitig stoppt.
- Jack Trefon: Das Gegenteil gilt für Codierungsagenten. Schränkt man einen ein, zerstört man seine Nützlichkeit; daher sollte man den Wirkungsradius in Kauf nehmen und in Tracking und schnelle Wiederherstellung investieren.
- Luis Rodríguez Berzosa: Eine dritte Linie. Behandeln Sie Frontier-Modelle wie Malware, konzipieren Sie das System so, dass jeder spezialisierte Agent eingeschränkt wird, und fügen Sie darunter eine Durchsetzungsebene ein, die greift, wenn alles darüber Versagen eintritt.
Der Ort, an dem sich alle drei trafen: Was man nicht inventarisiert hat, kann man nicht schützen; jede Aktion muss protokolliert werden, und das, was einen Agenten stoppt, muss außerhalb des Agenten liegen.
Es wurde nichts verletzt.
Der Agent hat seine Aufgabe erfüllt. Dabei entschied er, dass er eine Abhängigkeit, eine Konfiguration oder einen Dienst bearbeiten musste, ohne dass ihn jemand dazu aufgefordert hatte. Er bewegte sich dabei stets innerhalb seiner Berechtigungen. Da keine Regel verletzt wurde, wurde keine Ausnahme ausgelöst.
Wir legten den Fall drei Fachleuten vor, die sich beruflich damit befassen, und erwarteten eine breite Übereinstimmung hinsichtlich des weiteren Vorgehens. Wir erhielten drei unterschiedliche Antworten, von denen sich zwei widersprechen.
Das Risiko von agentenbasierter KI wird üblicherweise als Angreiferproblem beschrieben. Dies ist die andere Seite der Medaille. Zwanzig Jahre lang haben wir Berechtigungen um Software herum festgelegt, die exakt das tat, was ihr befohlen wurde: ein Dienstkonto, ein CI-Runner, ein geplanter Job. Wir haben die Berechtigungsgrenzen oft genug falsch gesetzt, aber der Inhalt war vorhersehbar. Er erledigte immer dieselbe Aufgabe auf dieselbe Weise.
Das, was sich innerhalb der Grenzen befindet, entscheidet nun. Und die Grenzen werden nach wie vor so gezogen wie eh und je: im Voraus, bei der Konfiguration, von jemandem, der nicht wissen kann, was aus der Aufgabe werden wird.
Das ist die Version des Risikos agentischer KI, über die es sich zu diskutieren lohnt, und wir haben im letzten SafeDev-Gespräch und Pedro Fortuna von Jscrambler, Jack Trefon von Trefon Digital Consulting und Luis Rodríguez Berzosa von Xygeni, gehostet von Alejandro Estrada.
Wir hatten erwartet, dass sie weitgehend zustimmen würden. Das taten sie nicht.
Das Risiko agentischer KI: die tröstliche Annahme, die nicht zutrifft
Im obigen Rahmen wird einem Wort mehr Bedeutung beigemessen, als ihm zukommt: AngreiferEs gibt keinen. Das soll die Situation vereinfachen.
Pedro hat das mit einem Schlag auseinandergenommen.
„Ob man ein Angreifer ist oder nicht, ist ein menschliches Konzept. Was einen Angreifer zum Angreifer macht, sind seine unterschiedlichen Ziele. Und auch ein fehlgeleiteter Akteur verfolgt andere Ziele.“
Denken Sie darüber nach, denn es widerlegt die Grundannahme der meisten Diskussionen über Risiken von agentenbasierter KI, einschließlich der Beschreibung, die wir für unsere eigene Veranstaltung verfasst haben. Wenn ein Angreifer nicht durch böswillige Absicht, sondern durch abweichende Ziele definiert wird, dann ist die Aussage „In dieser Geschichte gibt es keinen Angreifer“ ein Trost, den sich niemand verdient hat. Strukturell gesehen ist es dasselbe Risiko. Was fehlt, ist die Absicht, und Absicht war nie das, was Ihre Kontrollmechanismen erkannt haben. Sie erkennen Auswirkungen. Das haben sie schon immer getan.
Das ist auch der Grund, warum sich die Fachsprache der Branche verändert hat. OWASP Top 10 der LLM-Bewerbungen 2026 übermäßige Handlungsfähigkeit wurde vom sechsten auf den dritten Platz befördert, was weniger eine Meinungsänderung als vielmehr das Einholen der Vorfallsstatistik in eine bereits implementierte Architektur darstellt.
Was der Vorfall mit dem umarmenden Gesicht tatsächlich zeigt
Der Vorfall im Juli, bei dem ein Model aus der Grenzregion eine dritte Person angriff, wurde weithin als Geschichte über ein Model, das sich selbst auf die schiefe Bahn gebracht hatte, interpretiert. Luis sieht das anders, und seine Version verortet die Verantwortung an einem unbequemen Ort.
„Das Problem liegt nicht im Grenzmodell. Das Grenzmodell hat genau das getan, was ihm aufgetragen wurde. Das Problem liegt im Versuchsaufbau.“
Das Ziel war offen formuliert. Es gab keine Einschränkungen. Und die Sandbox, die sie eigentlich umfassen sollte, hatte über eine serverseitige Request-Forgery-Schwachstelle im Paketcache, auf die der Agent zugreifen konnte, ein Fenster zum Internet. Jede dieser Tatsachen ist ein Designfehler.cisvon einer Person hergestelltes Ion.
Daraus ergibt sich der Satz, der die Art und Weise der Bereitstellung dieser Dinge verändern sollte:
„Frontier-Modelle müssen wie Schadsoftware betrachtet werden, da sie autonom agieren und die Kontrolle übernehmen können.“cisIonen, die bösartig sind. Nicht absichtlich, aber letztendlich sind sie es wirklich.“
Nicht als Beleidigung des Modells, sondern als Vorsichtsmaßnahme. Man gibt Schadsoftware ja auch keine Bash-Shell und hofft, dass das Ziel klar definiert war.
Pedros Interpretation desselben Vorfalls bezog sich eher auf den Zeitpunkt als auf die Absicht:
„Sobald Sie feststellen, dass Agenten über Ordnernamen auf einem Dienst kommunizieren, den sie nicht nutzen sollten, müssen Sie diese Agenten stoppen. Sie müssen nicht warten, bis diese Agenten erfolgreich in Hugging Face eindringen, um zu entscheiden, ob dies böswillig ist oder nicht.“
Ein Detail der Reaktion ist ebenfalls erwähnenswert. Die Einsatzkräfte versuchten, die Spuren mithilfe eines kommerziellen Analysetools zu untersuchen, scheiterten jedoch an Ratenbegrenzungen. Der Angreifer kannte keine solche Begrenzung. „Der Angriff selbst wies eine Asymmetrie auf.“
Die eigentliche Frage: Den Agenten einschränken oder sich schneller erholen?
Hier spaltete sich das Panel, und es handelt sich um eine echte Meinungsverschiedenheit zwischen Praktikern, die sich ihren Platz jeweils redlich verdient haben.
Pedro plädiert für die Dekomposition. Fünfzehn Jahre Erfahrung mit der Isolation innerhalb des Browsers lehrten ihn, dass man bei einem monolithischen System zur Laufzeit nichts erzwingen kann. Man muss die Architektur in kleine, funktionsspezifische Einheiten zerlegen, erst dann finden Kontroll- und Überwachungspunkte einen Anknüpfungspunkt. Agenten bilden da keine Ausnahme.
„Ich denke, man muss das Ganze in sehr spezifische Agenten aufteilen, die jeweils nur für bestimmte Aufgaben vorgesehen sind. Und es spielt keine Rolle, ob man am Ende fünfzig Agenten hat. Das ist besser, als nur einen einzigen zu haben.“
Jack argumentiert das Gegenteil, und zwar speziell im Hinblick auf Codierungsagenten. Man würde erwarten, dass ein Hintergrund im Technologiebereich einer regulierten Kryptobörse die restriktivste Position im Raum einnimmt. Tatsächlich war dies der Fall.
Seine Ausgangsanalogie ist überhaupt kein Bedrohungsmodell:
„Ich betrachte einen typischen Agenteneinsatz genauso wie die Einstellung einer neuen Person. Diese Person kann die Aufgabe fehlerfrei ausführen oder einen Fehler machen. Ich sehe da keinen großen Unterschied.“
Bei spezialisierten Agenten ist er genauso streng wie alle anderen. Als er einen reinen Lese-Review-Agenten beschrieb, den er gerade entwickelt, machte er deutlich, dass die gängige Konfiguration nicht zu rechtfertigen sei: Die Bereitstellung auf einem Standard-Linux-System mit Bash-Zugriff „öffnet das gesamte Ökosystem der Bedrohungen“. Bei allgemeinen Codierungsagenten kehrt sich die Logik jedoch um, und er weiß, dass diese Position unpopulär ist:
„Je mehr Macht der Agent hat, desto kreativer und effektiver ist er. Es ist also nicht die Branche, die aufgrund von Einschränkungen und einer Verengung des Handlungsspielraums floriert.“
Was bleibt also übrig, wenn man keine Begrenzungen vornimmt? Schutzschalter und vor allem zeitbasierte Momentaufnahmen: Sie verhindern nicht den Explosionsradius, sondern ermöglichen eine schnelle und kostengünstige Wiederherstellung. Er integriert das in Bernstein, ein von Abhängigkeiten unabhängiges C++-Agenten-Framework, das er in seiner Freizeit schreibt, mit Snapshotting in der Schleife (Projektseite).
Und die Warnung davor, wo der andere Weg endet:
„Wenn wir anfangen, etwas wegzunehmen, bleibt am Ende nur noch ein Werkzeug übrig, und dieser Entwickler kann dann das Licht ein- und ausschalten.“
Luis nimmt den dritten Platz ein., was weder einschränken noch wiederherstellen, sondern von unten eindämmen ist: davon ausgehen, dass sich der Agent irgendwann wie Malware verhält, das Vorgehen so gestalten, dass jeder spezialisierte Agent eingeschränkt wird, und darunter eine Durchsetzungsebene einfügen, die greift, wenn alles darüber Versagen eintritt.
Drei Lösungsansätze für dasselbe Problem
Drei Positionen, jede mit ihren Kosten. Keine ist kostenlos, und keine bietet dem Agenten allein Sicherheit.
| Ansatz | Kernbewegung | Was es Sie kostet |
|---|---|---|
| ZersetzenPedro Fortuna | Viele kleine Agenten, jeder mit begrenzten Berechtigungen, plus Laufzeitüberwachung, die sie frühzeitig stoppt | Der Designaufwand im Vorfeld ist höher, während die offene Codierungsarbeit schwieriger zu bewältigen ist. |
| EntspannungJack Trefon | Die Funktionalität beibehalten, Schutzschalter und zeitbasierte Snapshots hinzufügen, damit ein Rollback kostengünstig ist. | Ein größerer Explosionsradius und die Wette, dass die Explosion rechtzeitig erkannt und rückgängig gemacht werden kann. |
| Von unten enthaltenLuis Rodríguez Berzosa | Gehen Sie vom Verhalten der Malware aus, beschränken Sie jeden Agenten im Rahmen des Frameworks und setzen Sie die entsprechenden Maßnahmen auf der Workstation und dem CI-Runner durch. | Infrastruktur und Tools, die die meisten Endpoint-Stacks noch nicht bieten |
Liest man die Texte nebeneinander, ist der Unterschied geringer als er zunächst scheint. Alle drei stimmen darin überein, dass der Agent etwas Unbeabsichtigtes tun wird. Sie unterscheiden sich jedoch darin, wohin das Geld fließt: in die Architektur vor Baubeginn, in die Sanierung nach Baubeginn oder in eine Zwischenetage.
Warum das Prinzip der minimalen Privilegien nicht zu einem Risiko für agentische KI führt
Das Prinzip der minimalen Berechtigungen setzt voraus, dass Sie die Aufgabe kennen. Sie beschränken die Berechtigungen auf die jeweilige Aufgabe.
Ein Agent bricht diese Regel stillschweigend, da seine Berechtigungsgrenzen bei der Konfiguration festgelegt werden und seine Aufgaben erst zur Laufzeit ausgeführt werden. Tatsächlich gewährt man ihm die Gesamtheit aller möglichen Aufgaben. Das ist nicht das Prinzip der minimalen Berechtigungen; es ist das genaue Gegenteil, nur im Gewand des Prinzips der minimalen Berechtigungen.
Luis bot eine Umdeutung an, die auf einer älteren Idee basierte als all das hier:
„Ich denke dabei an den UNIX-Mechanismus der Verkettung von Datenleitungen, bei dem einfache Werkzeuge miteinander verbunden werden, um eine komplexe Aufgabe zu erfüllen. Man kann spezifische Agenten mit einer kontrollierten Konfiguration definieren und so die Möglichkeiten dieses spezialisierten Agenten einschränken. Und man kann sie für nahezu jede Aufgabe kombinieren.“
Hinzu kommt eine zweite Designidee, die die meisten Teams noch nicht ausprobiert haben: Die Werkzeuge sollten eher umschlossen als die Berechtigungen erweitert werden. Nicht Bash, das das gesamte System freigibt, sondern ein schmaler Wrapper, der den einzigen aufrufbaren Pfad darstellt, wobei schreibgeschützte Varianten generische Wrapper umschließen. Der Agent erhält eine Berechtigung, keine Shell.
Er stellte außerdem klar, dass das Hindernis nicht im Design, sondern in der Implementierung liegt. Neue Kontrollmechanismen auf Entwicklerrechnern wurden schon immer umgangen, und daran ändert sich nichts, nur weil es sich bei dem betreffenden Tool um einen Agenten handelt.
Und wo er glaubt, dass alles endet:
„Ich denke, am Ende werden wir autonome Agenten haben, die andere autonome Agenten steuern.“
Der Laptop wurde zum Prunkstück, und Ihr EDR hat es nicht bemerkt.
Ein Agent benötigt dauerhaften Zugriff, um nützlich zu sein. Dazu gehören ein Token, das nicht mitten in einer Aufgabe abläuft, zwischengespeicherte Anmeldeinformationen, Push-Berechtigungen, Zugriff auf die Registrierung und ein direkter Pfad zum System. pipelineJede dieser Maßnahmen ist eine Notwendigkeit und kein Versehen, was bedeutet, dass mit zunehmender Verbesserung der Werkzeuge auch die Entwicklermaschine immer konzentrierter wurde.
Die Angreifer haben es zuerst bemerkt. Wie Pedro es ausdrückte: Sie sind keine Ideologen.
„Sie organisieren sich wie kleine Unternehmen. Sie müssen Geld verdienen, also konzentrieren sie sich auf den profitabelsten Ansatz, den sie finden können. Und sie haben schnell erkannt, dass sich mit Entwicklungsstationen Geld verdienen lässt.“
Wir beobachten jede Woche, wie sich diese Verschiebung in den Registern niederschlägt. Übersicht über bösartigen Code, wo Credential Harvester mittlerweile routinemäßig neben Cloud- und Registry-Schlüsseln auch KI-Anbieterschlüssel suchen.
Seine Liste der Gegenmaßnahmen ist unspektakulär, aber effektiv: Entfernen Sie alle Schlüssel, die nicht auf dem Rechner benötigt werden, koppeln Sie die verbleibenden Schlüssel mit einem zweiten Faktor wie OpenID Connect oder einem Hardware-Schlüssel, sodass ein gestohlenes Token allein nicht ausreicht, und verlagern Sie die Umgebung, wo immer möglich, vom Host, beispielsweise durch Entwicklungscontainer oder Cloud-IDEs.
Dann wies Luis auf einen Punkt hin, der jeden beunruhigen sollte, der davon ausgeht, dass sein Endpoint-Stack dies abdeckt:
„Die EDRs sind auf traditionelle Malware spezialisiert und kennen keine agentenbasierten Tools. Und selbst wenn sie funktionieren, können sie viele Fehlalarme auslösen, da der Agent Aktionen ausführt, die den aktuellen Erkennungsmustern unbekannt sind.“
Zwei Fehlerquellen gleichzeitig: Es übersieht Wichtiges und markiert Unwichtiges. Seine Lösung ist diese äußere Schutzschicht, die den Entwicklerarbeitsplatz und den CI-Runner umgibt, unterhalb des Frameworks, und den Aktionsradius eines fehlerhaften Agenten begrenzt. Das ist die Lücke. Xygeni Shield wurde so konzipiert, dass die Richtlinien auf dem Endpunkt durchgesetzt werden, auf dem die Installation tatsächlich stattfindet.
Jack drückte es noch deutlicher aus: Bewahren Sie Ihre Bitcoins nicht auf Ihrem Entwicklungsrechner auf.
Der Boden, auf den sich alle drei geeinigt hatten
Drei verschiedene Antworten, ein gemeinsames Minimum.
- Zuerst die Bestandsaufnahme. „Man kann nicht schützen, was man nicht kennt.“ Jede andere decision hängt davon ab, zu wissen, welche Agenten, Fähigkeiten und MCP-Server existieren, und fast keiner davon wurde angegeben.
- Jede Aktion protokollieren. Jack und Luis kamen aus entgegengesetzten Richtungen hierher. Jack sucht nach Spuren, weil sie die Grundlage für die Rekonstruktion und die Entwicklung einer Organisation bilden. Luis braucht sie, weil man ohne sie den Explosionsradius nicht rekonstruieren kann. Jacks Ansatz ist aufschlussreich: Es bringt nichts, den Akteur – ob Mensch oder Agent – zu befragen, sondern nur, den Kontext so gut zu verstehen, dass man ihn nicht wiederholt.
- Das, was einen Agenten aufhält, muss außerhalb des Agenten liegen. Pedros Laufzeitüberwachung, Luis' Durchsetzungsschicht, Jacks Schutzmechanismen und Snapshots. Unterschiedliche Mechanismen, ein Prinzip.
Jack lieferte eine hilfreiche Einschätzung der aktuellen Situation der Branche. Er erinnert sich an die erste Spam-E-Mail, die er je erhalten hat und in der ihm mitgeteilt wurde, er habe eine Goldmine in Nigeria geerbt. Das ist ein Reifeproblem, und Reife entwickelt sich erst nach den Fehlern, nicht davor.
Was man vor Freitag tun sollte
Wählen Sie einen Agenten aus. Erstellen Sie zwei Listen: eine Liste mit den Aufgaben, die er laut Gesetz erledigen darf, und eine Liste mit den Aufgaben, die er diese Woche tatsächlich erledigen musste.
Die Differenz zwischen diesen Listen entspricht Ihrem Gefahrenradius und ist das aussagekräftigste Maß für das Risiko durch agentenbasierte KI, das Ihr Team an einem Nachmittag ermitteln kann. Es benötigt nur einen Nachmittag, kein Budget und klärt die oben genannte Frage für Ihr Unternehmen, denn die drei Positionen stellen im Grunde drei unterschiedliche Antworten auf die Frage dar, wie groß diese Differenz sein sollte.
Die meisten Teams haben es nie aufgeschrieben.
Das volle Stunde ist als Aufzeichnung verfügbar, einschließlich Jacks Ausführungen darüber, warum die Anforderungen an die menschliche Beteiligung in Europa einige KI-Abwehrmechanismen in der Praxis unmöglich machen.
Und wenn der/die Übungcise liefert eine Antwort, die Ihnen nicht gefällt. Xygeni Entdecken Sie alle KI-Ressourcen in Ihren Repositories, einschließlich der Agenten, Fähigkeiten und MCP-Server, die niemand angegeben hat, und sehen Sie, was jede einzelne erreichen kann. Kontakt or kostenlos starten und wir werden es auf Ihrem System ausführen.
FAQ
Welchen Wirkungsradius hat ein KI-Agent?
Alles, was der Agent im Fehlerfall erreichen könnte, im Gegensatz zu dem, was er eigentlich tun sollte. Es wird durch die Berechtigungen, Anmeldeinformationen und Tools definiert, die ihm zur Laufzeit zur Verfügung stehen, nicht durch die Aufgabe selbst. Die Differenz zwischen diesen beiden Aspekten ist der entscheidende Faktor, und die meisten Teams haben sie nie dokumentiert.
Stellt das Überschreiten der Aufgaben durch einen Agenten einen Sicherheitsvorfall dar, wenn dieser seine Berechtigungen nie überschritten hat?
Das war der zentrale Streitpunkt. Pedros Antwort lautet im Grunde ja, da ein Angreifer eher durch Zielabweichungen als durch böswillige Absicht definiert wird und ein nicht ausgerichteter Agent abgewichen ist. Jacks Antwort geht eher in Richtung nein: Es handelt sich um einen operativen Fehler, vergleichbar mit einem Fehler eines neuen Mitarbeiters, und die richtige Reaktion besteht in der Nachverfolgung und Wiederherstellung des Fehlers, nicht in strengeren Beschränkungen. Luis umgeht die Frage, indem er von vornherein vom schlimmsten Fall ausgeht und fragt, welche Sicherheitsebene dann noch greift.
Sollten Codierungsagenten in einer Sandbox ausgeführt werden?
Für spezialisierte, aufgabenbezogene Agenten stimmten alle drei ohne Zögern zu: möglichst nur lesend, keine Bash-Shell, kein Netzwerkzugriff, außer bei Bedarf. Bei allgemeinen Codierungsagenten gab es drei unterschiedliche Meinungen: Pedro würde sie zerlegen, Jack würde die Funktionalität beibehalten und konsequent Snapshots erstellen, und Luis würde unabhängig von den Berechtigungen des Agenten eine zusätzliche Sicherheitsebene unterhalb des Frameworks einbauen.
Deckt meine EDR-Lösung auch Risiken durch agentenbasierte KI ab?
Vermutlich nicht gut. Aktuelle Endpoint-Tools basieren auf traditionellen Malware-Mustern und bilden das Verhalten von Agenten nicht ab. Daher übersehen sie oft Wichtiges und melden fälschlicherweise etwas, das irrelevant ist. Luis' Lösung war eine äußere Durchsetzungsschicht, die speziell für Entwicklerumgebungen konzipiert wurde, anstatt ein universelles EDR-System zu sein.
Was ist der allererste Schritt?
Erstellen Sie das Inventar. Jedes Modell, jeder Agent, jede Fähigkeit und jeder MCP-Server in Ihren Repositories sowie dessen jeweilige Reichweite. Dies ist der eine Schritt, den alle drei Diskussionsteilnehmer genannt haben, und der einzige, von dem alle anderen Kontrollmechanismen abhängen.
