Der wichtige Begriff ist hier gegebenenfalls. Nicht jede Handlung einer höheren Risikoklasse muss zwangsläufig durch einen Menschen geprüft werden. Manche lassen sich durch streng begrenzte, vorab genehmigte Regeln ebenfalls automatisieren.

Beispielsweise könnte ein Agent selbstständig Termine mit bereits autorisierten Geschäftspartnern koordinieren. Er müsste aber eine Anfrage ablehnen oder zur Freigabe vorlegen, wenn sie außerhalb dieses Rahmens liegt.

Der Mensch würde dann nicht den Arbeitsprozess überwachen, sondern die Regeln festlegen und nur bei relevanten Grenzfällen eingreifen.

So entsteht eine Form der Autonomie, bei der der Agent nicht für jeden Arbeitsschritt um Erlaubnis bitten muss.

Was ist mit der mangelnden Nachvollziehbarkeit?

Hier ist eine wichtige Unterscheidung nötig: Es ist nicht zwingend erforderlich, jeden internen Gedankenschritt eines Sprachmodells nachvollziehen zu können, um einen Agenten wirksam zu kontrollieren.

Entscheidend ist zunächst, seine tatsächlichen Handlungen nachvollziehen zu können.

Dazu gehören insbesondere:

• Welche Werkzeuge und Schnittstellen hat er aufgerufen?

• Welche Daten hat er dabei gelesen oder verändert?

• Welche Empfänger, Dateien oder Systeme waren betroffen?

• Welche Berechtigungsprüfung wurde durchgeführt?

• Welche Aktionen wurden blockiert, ausgeführt oder rückgängig gemacht?

Diese Ereignisse sollten in manipulationsgeschützten Protokollen festgehalten werden. Dazu kommen Grenzen für Laufzeit, Anzahl der Aktionen, Datenübertragung und gegebenenfalls Ausgaben. Bei kritischen Vorfällen muss der Agent gestoppt und sein Zugriff entzogen werden können.

Das ersetzt nicht jede Form der Überwachung. Es verschiebt sie aber von der kaum praktikablen Beobachtung sämtlicher interner Verarbeitung auf die überprüfbaren Grenzen und Auswirkungen des Systems.

Ein solcher Ansatz ist besonders dann wirkungsvoll, wenn die Kontrollinstanz einen Angriff bereits blockiert, bevor eine irreversible Handlung ausgeführt wird. Protokolle, die einen Vorfall erst im Nachhinein sichtbar machen, sind dagegen eine wichtige Ergänzung, aber kein ausreichender Schutz.

5. Und was passiert, wenn trotz allem eine Prompt Injection erfolgreich ist?

Hier liegt der vielleicht wichtigste Punkt meiner Antwort.

Man muss damit rechnen, dass Sicherheitsmechanismen versagen können. Ein Agent könnte eine manipulierte Anweisung falsch bewerten, eine Kontrollregel könnte einen Fall übersehen oder ein Sicherheitsmechanismus könnte selbst eine Schwachstelle enthalten.

Deshalb muss die Architektur nicht nur die Wahrscheinlichkeit eines Angriffs reduzieren. Sie muss auch dessen mögliche Folgen begrenzen.

Dazu würde ich mindestens vier weitere Maßnahmen als Grundvoraussetzungen betrachten:

Isolierte Ausführungsumgebung: Der Agent sollte möglichst in einer Sandbox oder einem separaten Konto arbeiten und nicht ohne Not auf das gesamte Betriebssystem, sämtliche Dateien und alle Zugangsdaten zugreifen können.

Begrenzte, kurzlebige Berechtigungen: Ein Agent sollte nur die Berechtigungen für die konkrete Aufgabe erhalten, die er gerade erledigt. Nach Abschluss werden diese entzogen oder laufen automatisch ab. Insbesondere darf das Modell seine eigenen Berechtigungen nicht erweitern können.

Kontrollierte Ausgänge: Daten dürfen nicht beliebig an externe Adressen, Dienste oder Empfänger gesendet werden. Besonders bei sensiblen Informationen muss die Weitergabe separat autorisiert werden.

Begrenzter Schaden: Wo es möglich ist, sollte der Agent mit Kopien, Entwürfen, reversiblen Änderungen und klaren Ausgabenlimits arbeiten. Eine fehlerhafte Aktion darf nicht automatisch zur dauerhaften Löschung, zu einer unkontrollierten Geldbewegung oder zum Verlust umfassender Systemrechte führen.

Damit verändert sich das Sicherheitsziel.

Es lautet nicht mehr:

Wie verhindere ich unter allen Umständen, dass der Agent manipuliert wird?

Sondern:

Wie konstruiere ich das System so, dass selbst ein erfolgreich manipulierter Agent nur einen begrenzten, vorher definierten Schaden verursachen kann?

Genau in diese Richtung argumentiert auch das britische National Cyber Security Centre: Sicherheitsmaßnahmen sollen vor allem die tatsächlichen Handlungsmöglichkeiten eines potenziell manipulierten Systems begrenzen. Falls die Sicherheit eines Anwendungsfalls das verbleibende Risiko nicht verträgt, ist dieser Anwendungsfall unter Umständen ungeeignet für eine LLM-basierte Lösung. (NCSC)

 

6. Wo bleibt dann noch das Problem?

Nach diesen Überlegungen könnte man einwenden, dass das Sicherheitsproblem lediglich in die Kontrollinstanz verschoben wurde.

Dieser Einwand ist teilweise richtig.

Die Kontrollinstanz muss selbst sicher implementiert werden. Ihre Regeln müssen vollständig genug sein, um die relevanten Risiken abzudecken. Auch die Schnittstellen, auf die sie zugreift, können Fehler enthalten. Es ist daher keineswegs garantiert, dass eine Kombination aus Berechtigungen, Datenflusskontrollen und Protokollen immer sicher ist.

Es gibt zudem eine Grenze, die man nicht allein durch technische Architektur aufheben kann.

Je offener die Aufgabe formuliert ist, je mehr Systeme und Daten der Agent benötigt und je weniger sich zulässige und unzulässige Handlungen vorab unterscheiden lassen, desto schwieriger wird es, eine wirksame Sicherheitsgrenze zu definieren.

Ein Agent, der eigenständig ein Hotelzimmer recherchiert und eine Zusammenfassung erstellt, ist wesentlich einfacher abzusichern als ein Agent, der uneingeschränkt mit sämtlichen internen Geschäftsdaten, externen Kommunikationskanälen, administrativen Systemen und Zahlungsfunktionen arbeiten darf.

Und manchmal kann der Sicherheitsmechanismus den Agenten tatsächlich daran hindern, eine neue, bislang nicht vorgesehene Handlung auszuführen, die für die Erledigung seiner Aufgabe erforderlich wäre.

Das ist kein zufälliger Implementierungsfehler, sondern ein grundsätzlicher Zielkonflikt: Je weniger die zulässigen Handlungen vorab eingegrenzt werden können, desto schwieriger ist es, die möglichen Folgen zuverlässig zu kontrollieren.

Die Forschung zu CaMeL zeigt, dass strukturelle Schutzmechanismen einen beträchtlichen Teil solcher Aufgaben abdecken können. Sie zeigt aber auch, dass sichere Ausführung und maximale Aufgabenabdeckung nicht automatisch zusammenfallen. (CaMeL-Forschungsarbeit)

Das bedeutet: Vollständige Autonomie über beliebige Ziele, Daten und Handlungen ist ein wesentlich schwierigeres Sicherheitsproblem als Autonomie innerhalb einer festgelegten Arbeitsumgebung.

7. Welche Konsequenzen sollte man daraus für die Praxis ziehen?

Ich würde drei Kategorien unterscheiden.

 Kategorie 1: Weitgehend autonom einsetzbar

Agenten, die überwiegend analysieren, recherchieren, strukturieren, vergleichen und Entwürfe erstellen, lassen sich mit überschaubaren Handlungsmöglichkeiten häufig sinnvoll einsetzen. Voraussetzung sind angemessene Datenschutzmaßnahmen und die Kontrolle ihrer Ausgaben.

 

Kategorie 2: Autonom innerhalb einer kontrollierten Umgebung

Agenten, die E-Mails versenden, Termine vereinbaren, Tickets bearbeiten oder Daten verändern, benötigen eine Architektur mit wirksamer Rechtebegrenzung, getrennten Berechtigungen, kontrollierten Datenflüssen und nachvollziehbaren Aktionen. Die verbleibenden Risiken müssen für den konkreten Einsatz akzeptabel sein.

 

Kategorie 3: Keine uneingeschränkte Autonomie

Bei hohen finanziellen Schäden, unwiederbringlichem Datenverlust, privilegierten Systemzugriffen oder anderen schwerwiegenden Folgen reicht es nicht, auf ein vermeintlich zuverlässiges Modell zu vertrauen. Wenn sich das verbleibende Risiko nicht ausreichend begrenzen lässt, sollte man die betreffende Handlung nicht autonom ausführen lassen.

 

Diese Kategorien sind keine starren technischen Grenzen. Sie verdeutlichen vielmehr eine Entscheidungsregel: Nicht die Leistungsfähigkeit des Agenten entscheidet allein darüber, ob eine Aufgabe delegierbar ist. Entscheidend ist auch, welche Schäden selbst dann noch möglich wären, wenn er einen Angriff nicht erkennt.

Ein Agent kann fachlich hervorragend sein und sich trotzdem für eine bestimmte Aufgabe nicht eignen, weil sein möglicher Fehltritt zu schwerwiegende Folgen hätte.

8. Meine Schlussfolgerung

Ich würde deiner Ausgangsthese in einem wesentlichen Punkt widersprechen: Autonomie und Sicherheit stehen nicht zwangsläufig im Verhältnis von entweder-oder.

Der Widerspruch entsteht vor allem dann, wenn wir Autonomie als das Recht eines Agenten verstehen, alle Handlungen auszuführen, die er aufgrund seiner eigenen Entscheidungen für notwendig hält.

Das ist aber nicht die einzige denkbare Form von Autonomie.

Ein Agent kann vollkommen selbstständig recherchieren, unterschiedliche Lösungswege ausprobieren, auf unerwartete Schwierigkeiten reagieren und eine mehrstufige Aufgabe erledigen, ohne gleichzeitig die Freiheit zu besitzen, vertrauliche Daten an beliebige Empfänger zu versenden, seine Berechtigungen zu erweitern oder irreversible Veränderungen ohne ausreichende Autorisierung vorzunehmen.

Die Selbstständigkeit liegt dann in der Problemlösung. Die Sicherheitsgrenzen liegen außerhalb des Modells.

Ich würde allerdings drei Einschränkungen ausdrücklich festhalten:

Erstens: Diese Architektur garantiert nicht, dass jeder Agent gegen jede Manipulation geschützt ist. Sie kann aber verhindern, dass eine manipulierte Entscheidung automatisch alle vorhandenen Berechtigungen ausschöpft.

Zweitens: Die Schutzmechanismen müssen technisch unabhängig vom Agenten durchgesetzt werden. Ein zweites Sprachmodell, das den ersten Agenten überwacht, ist allein keine ausreichende Lösung, denn auch dieses zweite Modell kann durch geeignete Eingaben beeinflusst werden.

Drittens: Es wird Aufgaben geben, bei denen ein ausreichend niedriges Restrisiko nur dadurch erreicht werden kann, dass bestimmte Aktionen menschlich freigegeben oder vollständig ausgeschlossen werden. Das ist keine Niederlage der Technik, sondern eine Grenze dessen, was sich verantwortbar delegieren lässt.

Der entscheidende Maßstab sollte deshalb nicht sein, wie autonom ein Agent handeln kann, sondern wie viel Schaden er selbst im ungünstigsten realistischen Fall anrichten kann.

Wenn diese Schadensgrenze niedrig genug ist, kann ein Agent ein hohes Maß an operativer Autonomie erhalten, ohne dass man jeden Arbeitsschritt überwachen muss. Wenn sie sich nicht ausreichend begrenzen lässt, sollte man ihm die betreffende Handlungsmacht nicht übertragen – unabhängig davon, wie beeindruckend seine Fähigkeiten sind.

Darin sehe ich den derzeit aussichtsreichsten Weg: nicht die Hoffnung, einen unfehlbaren Agenten zu konstruieren, sondern die Entwicklung von Systemen, die auch mit einem fehlbaren Agenten verantwortbar umgehen können.