Übermäßige Eigenmächtigkeit

Von übermäßiger Handlungsautonomie spricht man, wenn einem LLM-basierten System mehr Fähigkeiten, Berechtigungen oder Autonomie eingeräumt werden, als erforderlich ist, wodurch es in die Lage versetzt wird, als Reaktion auf unerwartete, mehrdeutige, halluzinierte oder manipulierte Ausgaben schädliche Handlungen auszuführen.

Moderne LLM-Anwendungen lassen sich häufig über Erweiterungen (Tools, Plugins oder Skills) in externe Systeme integrieren. In agentenbasierten Architekturen kann das Modell dynamisch entscheiden, welches Tool aufgerufen werden soll, und Tools auf der Grundlage früherer Ausgaben wiederholt aufrufen. Wenn diese Fähigkeiten nicht streng eingeschränkt werden, kann das System schädliche Aktionen ausführen, selbst wenn die Ursache Halluzinationen oder Konfabulationen, mangelhafte Prompt-Engineering, direkte oder indirekte Prompt-Injektion, kompromittierte Erweiterungen oder böswillige Peer-Agenten in Multi-Agenten-Systemen sind.

Übermäßige Eigenwirksamkeit ist im Grunde genommen ein Versagen in Bezug auf Privilegien und Kontrolle und nicht nur ein Problem der Modellgenauigkeit.

Anmerkung: Übermäßige Handlungsfreiheit unterscheidet sich von unsachgemäßer Umgang mit den Ausgaben. Bei unsachgemäßem Umgang mit den Ausgaben geht es um eine unzureichende Überprüfung der Ausgaben des großen Sprachmodells vor deren Verwendung. Bei übermäßiger Handlungsfreiheit geht es darum, was das große Sprachmodell mit diesen Ausgaben tun darf.

Die eigentlichen Ursachen für übermäßige Eigeninitiative

Übermäßige Autonomie hat in der Regel eine oder mehrere Ursachen. Erstens: Übermäßige Funktionalität – das LLM hat Zugriff auf Tools oder Funktionen, die über das erforderliche Maß hinausgehen. Zweitens: Übermäßige Berechtigungen – das LLM oder seine Erweiterungen arbeiten mit mehr Berechtigungen, als notwendig sind. Drittens: Übermäßige Autonomie – Maßnahmen mit erheblichen Auswirkungen werden ohne unabhängige Überprüfung oder menschliche Aufsicht ausgeführt. Diese Schwachstellen können sich auf Vertraulichkeit, Integrität und Verfügbarkeit auswirken, je nachdem, auf welche Systeme das LLM zugreifen kann. Konkrete Beispiele sind im Folgenden aufgeführt.

• Übermäßige Funktionalität: Ein LLM-Agent muss lediglich Dokumente lesen, doch die gewählte Erweiterung ermöglicht es ihm auch, Dokumente zu ändern oder zu löschen; ein veraltetes Plug-in bleibt auch nach seinem Austausch aktiviert; eine Shell-Befehlserweiterung erlaubt die Ausführung beliebiger Befehle anstelle einer einzigen, eingeschränkten Operation. Offen gestaltete Erweiterungen (z. B. „Shell-Befehl ausführen“, „URL abrufen“) vergrößern die Angriffsfläche erheblich.
• Übermäßige Berechtigungen: Eine Datenbankerweiterung, die für den schreibgeschützten Zugriff vorgesehen ist, stellt eine Verbindung unter Verwendung von Anmeldedaten mit INSERT-, UPDATE- und DELETE-Berechtigungen her; eine Erweiterung, die im Namen eines Benutzers agiert, stellt eine Verbindung über ein generisches Konto mit weitreichenden Berechtigungen her, wodurch der benutzerübergreifende Datenzugriff ermöglicht wird. Wird das Prinzip der geringsten Berechtigungen auf der Ebene des nachgelagerten Systems nicht durchgesetzt, ist eine Ausweitung von Berechtigungen möglich.
• Übermäßige Autonomie: Eine Erweiterung löscht Dokumente ohne Bestätigung durch den Benutzer; ein Tool zur Automatisierung sozialer Medien veröffentlicht Inhalte ohne Genehmigung; eine Finanztransaktion wird ohne unabhängige Überprüfung ausgeführt. Die autonome Ausführung von Maßnahmen mit weitreichenden Folgen erhöht das Risiko exponentiell.

Beispiel für ein Angriffsszenario

Ein LLM-gestützter persönlicher Assistent fasst E-Mails mithilfe einer E-Mail-Erweiterung zusammen. Die Erweiterung umfasst sowohl Funktionen zum Lesen als auch zum Versenden von E-Mails. Sie authentifiziert sich über umfassende E-Mail-Berechtigungen und benötigt vor dem Versenden von E-Mails keine Genehmigung.

Das System ist anfällig für indirekte Eingabeaufforderungen. Eine bösartige E-Mail weist das LLM an, den Posteingang nach sensiblen Informationen zu durchsuchen. Anschließend fasst es diese zusammen und sendet sie an den Angreifer. Aufgrund übermäßiger Funktionalität, übermäßiger Berechtigungen und übermäßiger Autonomie kann das LLM sensible Daten abziehen.

Dies hätte verhindert werden können, indem eine schreibgeschützte Erweiterung verwendet, OAuth mit schreibgeschütztem Zugriffsbereich erzwungen und vor dem Senden von Nachrichten eine manuelle Zustimmung des Benutzers verlangt worden wäre.

Strategien zur Prävention und Schadensminderung

• Erweiterungen minimieren: Gewähren Sie dem LLM nur Zugriff auf die Tools, die für den Betrieb unbedingt erforderlich sind. Wenn das Abrufen von URLs nicht erforderlich ist, aktivieren Sie diese Funktion nicht.
• Funktionalität der Erweiterungen minimieren: Entwickeln Sie Erweiterungen, die vorzugsweise nur bestimmte erforderliche Aktionen ausführen, z. B. „in eine bestimmte Datei schreiben“ statt „Shell-Befehl ausführen“. Eine feinkörnige Struktur verringert das Risiko.
• Vermeiden Sie zu weit gefasste Erweiterungen: Vermeiden Sie allgemeine Ausführungsschnittstellen wie „beliebigen Shell-Befehl ausführen“ und „beliebige URL abrufen“. Ersetzen Sie allgemeine Ausführungsschnittstellen durch APIs mit eng gefasstem Anwendungsbereich.
• Erweiterungsberechtigungen minimieren: Wenden Sie das Prinzip der geringsten Berechtigungen auf nachgelagerte Systeme an, z. B. durch schreibgeschützten Datenbankzugriff, wo dies möglich ist, sowie durch das Unterlassen von Schreib- und Löschvorgängen, sofern nicht erforderlich, und durch das Unterbinden benutzerübergreifender Zugriffe. Setzen Sie dies auf Infrastrukturebene durch, nicht über LLM-Logik.
• Im Benutzerkontext ausführen: Stellen Sie sicher, dass im Namen von Benutzern durchgeführte Aktionen mit OAuth-Authentifizierung, dem minimal erforderlichen Zugriffsbereich und unter der richtigen Benutzeridentität ausgeführt werden. Verwenden Sie niemals generische Dienstkonten mit hohen Berechtigungen für Aktionen im Benutzerkontext.
• Menschliche Freigabe erforderlich: Führen Sie „Human-in-the-Loop“-Kontrollen für Maßnahmen mit erheblichen Auswirkungen ein, wie z. B. das Versenden von Nachrichten, das Veröffentlichen von Inhalten, das Löschen von Daten und die Durchführung von Finanztransaktionen. Die Autonomie muss begrenzt sein.
• Vollständige Vermittlung: Verlassen Sie sich nicht auf den LLM, um zu entscheiden, ob eine Aktion autorisiert ist. Alle nachgelagerten Systeme müssen die Autorisierungs- und Richtlinienprüfungen eigenständig durchführen.
• Eingaben und Ausgaben bereinigen: Wenden Sie sichere Programmierpraktiken an (z. B. die OWASP-ASVS-Richtlinien) und nutzen Sie SAST, DAST und IAST. Befolgen Sie bewährte Verfahren zur Eingabevalidierung und Ausgabeverarbeitung, um das Risiko von Injektionen zu verringern.

Maßnahmen zur Schadensbegrenzung

Das Protokollieren und Überwachen der Aktivitäten von Erweiterungen, das Beobachten der Aktionen nachgelagerter Systeme, der Einsatz von Tools zur Begrenzung der Aufrufhäufigkeit sowie Warnmeldungen bei ungewöhnlichen Mustern können dazu beitragen, die Auswirkungen übermäßiger Agentenaktivität zu verringern. Diese Techniken verbessern die Erkennungsfähigkeit, bevor weitreichende Schäden entstehen.

Das zentrale Sicherheitsprinzip

Übermäßige Autonomie ist ein Problem der unkontrollierten Macht. Wenn LLMs auf leistungsstarke Tools zugreifen, mit weitreichenden Berechtigungen arbeiten oder autonom handeln dürfen, werden sie zu risikoreichen Automatisierungssystemen. Eine sichere LLM-Architektur erfordert ein Minimum an Funktionalität, das Prinzip der geringsten Berechtigungen, kontrollierte Autonomie, eine unabhängige Durchsetzung von Berechtigungen sowie menschliche Aufsicht bei Vorgängen mit erheblichen Auswirkungen.

Großsprachenmodelle sollten Entscheidungen unterstützen, nicht eigenmächtig umsetzen. Begrenzen Sie die Werkzeuge, begrenzen Sie die Berechtigungen und begrenzen Sie die Autonomie.