Großskalige Sprachmodelle und Agentensicherheit: Warum Kontrollmaßnahmen über das Modell hinausgehen müssen

Modellbezogene Sicherheitsvorkehrungen bilden eine wichtige Grundlage. Unternehmen benötigen darüber hinaus unabhängige Kontrollmechanismen für die Daten, Berechtigungen, Tools und Vorgänge im Zusammenhang mit KI-Systemen.

Ein Modell kann eine unsichere Anfrage ablehnen und dennoch Teil einer unsicheren Anwendung sein. Stellen Sie sich einen Kundendienstmitarbeiter vor, der Kundendatensätze abrufen und E-Mails versenden kann. Ein Angreifer versteckt Anweisungen in einem Ticket, in denen der Mitarbeiter angewiesen wird, diese Datensätze an eine externe Adresse weiterzuleiten. Ob der Angriff erfolgreich ist, hängt nicht nur von der Fähigkeit des Modells ab, bösartigen Text zu erkennen. Es hängt auch davon ab, auf welche Datensätze der Mitarbeiter zugreifen kann, welche Empfänger er kontaktieren kann und ob der Versandvorgang separat autorisiert wird.

Aus diesem Grund muss die Sicherheit bei LLMs und Agenten über das Modellverhalten hinausgehen. Integrierte Sicherheitsvorkehrungen verringern das Risiko. Die das Modell umgebenden Systeme müssen die Folgen eines Fehlers oder eines erfolgreichen Angriffs begrenzen.

Leitfaden für Anbieter stellt die Verantwortlichkeiten klar

Die Sicherheitsrichtlinien von OpenAI empfehlen Moderation, adversarische Tests und die Überprüfung der Ergebnisse durch Menschen. Die Leitlinien für die Entwicklung von Agenten sehen zusätzlich Eingabebeschränkungen, strukturierte Datenflüsse und die Genehmigung von Tools vor, wobei anerkannt wird, dass Agenten dennoch Fehler machen oder ausgetrickst werden können. Diese Empfehlungen erfordern neben den vom Modell bereitgestellten Schutzmaßnahmen auch Sicherheitsvorkehrungen in der Anwendung und im Arbeitsablauf.

Anthropic weist in seiner Sicherheitsdokumentation zu „Managed Agents“ ausdrücklich auf diesen Unterschied hin: „Das Modellverhalten stellt keine Sicherheitsmaßnahme dar.“ Das Unternehmen empfiehlt, den Zugriff auf Tools zu beschränken, Netzwerkzugriffe einzuschränken und Genehmigungen für risikobehaftete Aktionen zu verlangen. Außerdem weist es darauf hin, dass seine Einstellungen weder die benutzerdefinierten Tools eines Kunden noch dessen MCP-Server oder selbst gehostete Infrastruktur schützen. Diese Bereiche fallen weiterhin in den Sicherheitsverantwortungsbereich des jeweiligen Einsatzes.

In den Leitlinien von Google Cloud für KI-Workloads auf GKE heißt es, dass der Kunde selbst dann, wenn ein verwaltetes Modell über integrierte Sicherheitsfilter verfügt, weiterhin für den Schutz vor Prompt-Injektionen im Rahmen seiner spezifischen Anwendungslogik verantwortlich ist. Es wird empfohlen, Prompts und Antworten zu überprüfen und „Model Armor“ zwischen der Anwendung und dem Inferenz-Endpunkt zu platzieren. Dies ist ein konkretes Beispiel für das Hinzufügen einer Sicherheitsebene rund um Modellinteraktionen.

Die Richtlinien von Microsoft zu Agenten empfehlen deterministische Kontrollmechanismen, die unzulässige Aktionen unabhängig von der Modellausgabe blockieren. Außerdem werden Bestandsaufnahmen der Agenten und ihrer Abhängigkeiten, das Prinzip der geringsten Berechtigungen sowie zuverlässige Mechanismen auf Systemebene zum Anhalten oder Beenden von Agenten gefordert. Das Modell der geteilten Verantwortung erläutert, wie sich die Zuständigkeiten je nach Bereitstellungsart ändern, wobei die Verantwortung des Kunden für Daten, Autorisierung und Überwachung erhalten bleibt.

Insgesamt unterstützen diese Leitlinien Kontrollmaßnahmen außerhalb des Modells. Sie legen nicht fest, dass jede Organisation ein separates Sicherheitsprodukt erwerben muss. Kontrollmaßnahmen können von einem Anbieter, einem internen Plattformteam oder einem Spezialisten bereitgestellt werden. Die architektonische Anforderung besteht darin, dass kritische Grenzen auch dann durchgesetzt werden können, wenn das Modellversagen auftritt.

Sicherheitskräfte machen aktive Sicherheit unverzichtbar

Bei einem textgenerierenden LLM umfasst die Sicherheit sowohl die Daten, die in den Kontext gelangen, als auch diejenigen, die die Anwendung verlassen. Ein Agent fügt einen Ausführungspfad hinzu. Er kann Tools auswählen, Zugangsdaten verwenden, Daten im Speicher behalten und systemübergreifende Änderungen auslösen. Eine problematische Ausgabe kann daher bereits zu einem Betriebsvorfall werden, noch bevor jemand die endgültige Antwort liest.

Ein Hinweis wie „Senden Sie niemals vertrauliche Informationen“ vermittelt eine Absicht. Eine Autorisierungsprüfung bei einem ausgehenden Tool-Aufruf setzt eine Grenze durch. Beides hat seine Berechtigung, bietet jedoch unterschiedliche Sicherheitsgarantien. Inhaltsklassifizierer und Schutzmodelle können dabei helfen, verdächtiges Verhalten zu erkennen; Aktionskontrollen müssen zudem die tatsächliche Ressource, den Vorgang und das Ziel überprüfen.

Fünf Funktionen, die zum KI-Stack gehören

Laufzeit-Sicherheitsvorkehrungen

Überprüfen Sie Benutzereingaben, abgerufene Inhalte, Tool-Antworten und Modellausgaben auf Prompt-Injection, die Offenlegung sensibler Daten und Richtlinienverstöße. Führen Sie Prüfungen dort durch, wo Daten Vertrauensgrenzen überschreiten, einschließlich Pfaden, die die Chat-Oberfläche nie erreichen. Legen Sie fest, was geschieht, wenn eine Prüfung ein Problem erkennt oder nicht mehr verfügbar ist. Ein Erkennungsereignis ist nur dann nützlich, wenn der Workflow angemessen darauf reagiert.

Werkzeug- und Zugriffskontrolle

Autorisieren Sie Aktionen unabhängig vom Modell. Schränken Sie die verfügbaren Tools ein und überprüfen Sie deren Parameter anhand der Berechtigungen des anfragenden Benutzers und der Aufgabe des Agenten. Bei MCP-Verbindungen (Model Context Protocol) regeln Sie den Serverzugriff, die Anmeldedaten und die freigegebenen Operationen. Ein zugelassenes Tool sollte dennoch nicht in der Lage sein, auf einen nicht autorisierten Datensatz zuzugreifen oder Daten an ein nicht genehmigtes Ziel zu senden.

Erkennung und Bestandsaufnahme von Agenten

Behalten Sie den Überblick über die bereitgestellten Agenten, deren Eigentümer, Modelle, verbundene Tools und den Datenzugriff. Berücksichtigen Sie dabei auch Agenten, die außerhalb der zentralen Plattform erstellt wurden, sowie delegierte Agenten, die von anderen Workflows gestartet wurden. Mithilfe der Erkennung lässt sich feststellen, wo ein genehmigtes Modell mit einer nicht genehmigten Funktion verbunden wurde oder wo sich die Berechtigungen seit der ursprünglichen Überprüfung erweitert haben.

Kill-Switches und Eindämmung

Stellen Sie eine administrative Möglichkeit bereit, die Ausführung eines Agenten zu stoppen und weitere Aktionen zu verhindern, ohne darauf angewiesen zu sein, dass der Agent einer Stoppanweisung Folge leistet. Je nach Architektur kann die Eindämmung erfordern, dass in der Warteschlange befindliche Aufgaben abgebrochen, delegierte Agenten gestoppt, der Zugriff auf Tools deaktiviert oder Zugangsdaten widerrufen werden. Testen Sie diese Mechanismen unter realistischen Bedingungen. Das Stoppen der zukünftigen Ausführung macht eine bereits abgeschlossene Zahlung nicht rückgängig und stellt bereits offengelegte Daten nicht wieder her.

Modell und Anwendung des Red-Teaming

Testen Sie das Verhalten des Modells und den gesamten bereitgestellten Workflow mithilfe von Red-Teaming. Berücksichtigen Sie dabei die indirekte Einfügung von Eingabeaufforderungen in Dokumente und Tool-Ergebnisse, den unbefugten Datenzugriff, den Missbrauch von Anmeldedaten sowie Versuche, die Genehmigung von Aktionen zu umgehen. Messen Sie, ob ein Angreifer das unerwünschte Ergebnis erreicht, und nicht nur, ob ein Detektor verdächtigen Text markiert. Wiederholen Sie die Tests, wenn sich Modelle, Eingabeaufforderungen, Tools, Berechtigungen oder Abrufquellen ändern. Anbieter-Tests können nicht die Sicherheit jeder Kundenintegration gewährleisten.

Einheitliche Vorgehensweise über alle Modelle und Rahmenwerke hinweg

Unternehmen, die mehrere Modellanbieter nutzen, benötigen eine einheitliche Methode, um ihre Richtlinien zu formulieren und durchzusetzen. Eine Einschränkung hinsichtlich Kundendaten sollte auch bei einem Modellwechsel bestehen bleiben. Genehmigungsanforderungen sollten weiterhin gelten, wenn ein Team ein neues Agenten-Framework einführt. Die Erkennung und die Reaktion auf Vorfälle sollten das gesamte eingesetzte System abdecken, einschließlich der Komponenten, die außerhalb des Sichtbereichs des Anbieters liegen.

Konsistenz bedeutet nicht, dass überall identische Kontrollmechanismen erforderlich sind. Ein Entwurfsassistent und ein Mitarbeiter mit Schreibzugriff auf die Produktion benötigen unterschiedliche Sicherheitsvorkehrungen. Die Abdeckung sollte sich an den tatsächlichen Daten- und Ausführungspfaden orientieren, wobei Lücken und Ausnahmen eindeutig zugeordnet sein müssen. Externe Schutzmechanismen erfordern zudem Tests, sorgfältige Berechtigungsvergabe und den Schutz der sensiblen Daten, die sie überwachen.

Bevor die Autonomie eines Agenten erweitert wird, sollten Teams nachweisen können, auf welche Ressourcen er zugreifen kann, wie Aktionen autorisiert werden, welche Ergebnisse bei Adversarial-Tests festgestellt wurden und wie die Ausführung gestoppt werden kann. Die Sicherheitsvorkehrungen des Anbieters sind Teil dieses Nachweises. Die Kontrollmaßnahmen im Zusammenhang mit der Bereitstellung vervollständigen ihn.