Sandboxing allein reicht bei KI-Agenten nicht aus Je mehr Zugriffsrechte ein KI-Agent hat, desto größer das Risiko

Ein Gastbeitrag von Jim Gumbley 4 min Lesedauer

Anbieter zum Thema

Ein Assistent, der WhatsApp-Nachrichten mitliest und im eigenen Namen antwortet, klingt praktisch, doch genau solche Agenten stehen im aktuellen Technology Radar von Thoughtworks unter Beobachtung. Sandboxing gilt als Standardschutz, reicht aber allein nicht aus, um sie sicher zu machen.

Sandboxing allein ersetzt keine menschliche Kontrolle: Ohne Aufsicht kann eine manipulierte Anweisung einen KI-Agenten unbemerkt zum Sicherheitsrisiko machen.(Bild:  Gemini / KI-generiert)
Sandboxing allein ersetzt keine menschliche Kontrolle: Ohne Aufsicht kann eine manipulierte Anweisung einen KI-Agenten unbemerkt zum Sicherheitsrisiko machen.
(Bild: Gemini / KI-generiert)

Tief integrierte KI-Agenten bieten ohne Zweifel zahlreiche Chancen. Doch um ihr Potenzial ausschöpfen zu können, benötigen sie oftmals weitreichenden Zugriff. Dies nimmt bisweilen ein kritisches Ausmaß an. Der Grund dafür liegt darin, dass die Agenten mit dem größten Potenzial – solche, die für eine tiefe Integration konzipiert sind – Zugriff auf private Daten, externe Kommunikationskanäle und reale Systeme benötigen. Dies ist Ursache für einen verbreiteten Zielkonflikt zwischen Zugänglichkeit und Informationssicherheit. Die Suche nach den optimal geeigneten Gegenmaßnahmen wird folglich immer dringlicher. Dies ist eine der wichtigsten Erkenntnisse aus dem aktuellen Technology Radar Report von Thoughtworks, der Trends in der Softwareentwicklung auf der Grundlage praktischer Kunden- und Projekterfahrungen bewertet.

Umfangreiche Berechtigungen, hohe Anfälligkeit

Ein Beispiel, bei dem im Radar-Report zur Vorsicht gemahnt wird, ist der KI-Agent OpenClaw. Dabei handelt es sich um einen interessanten neuen Open-Source-Assistenten mit hyper-personalisierten Funktionen. Er benötigt umfassenden Zugriff, um persönliche Nachrichten über Dienste wie WhatsApp oder iMessage zu lesen und zu versenden. Der Nutzen solcher Tools wächst parallel zu dem Umfang der Zugriffsrechte, die ihnen gewährt werden – beispielsweise auf persönliche E-Mails, Kalender und vertrauliche Dateien. Mit zunehmender Personalisierung steigt jedoch auch das Risiko, da sensible Berechtigungen gebündelt werden. Dieses Muster ist als sicherheitskritisch einzustufen: Ein umfassenderer Zugriff führt in der Folge de facto zu einem potenziell höheren Ausmaß an möglichen Auswirkungen.

Risiken werden besonders akut, wenn ein Agent nicht vertrauenswürdige Inhalte lesen, auf sensible Informationen zugreifen und im Namen eines Users Aktionen ausführen kann. In solch einer Situation können schädliche Anweisungen, versteckt in einer E-Mail, einer Webseite, einem Dokument oder einer Plugin-Antwort, den Agenten entsprechend dazu manipulieren, Daten preiszugeben, Anmeldedaten zu missbrauchen oder Aktionen auszuführen, die der User nicht beabsichtigt hat. Dies beschreibt die grundlegende Gefahr durch Prompt-Injection und Agent-Hijacking.

Solche Beispiele stehen nicht für ein singuläres Problem, sondern vielmehr für einen grundlegenden Zielkonflikt: Die Herausforderung besteht darin, die Grenze zwischen Nutzen und Risiko zu ziehen. Eine häufig gestellte Frage dabei ist, ob Sandboxing diesen Spannungszustand auflösen kann. Tatsächlich sollte die Praxis, Agenten in isolierten Umgebungen auszuführen – mit eingeschränktem Dateisystemzugriff, kontrollierter Netzwerkkonnektivität und begrenzter Ressourcennutzung – als Standardverfahren und nicht als bloßes optionales Zusatzmodul betrachtet werden.

In der Praxis kann Sandboxing allein jedoch die Sicherheitsherausforderungen nicht lösen, die von Agenten mit einem inhärenten Bedarf nach Zugriff ausgehen. Wenn ein Agent zu starken Einschränkungen unterworfen wird und ihm der Zugriff auf die Daten verwehrt wird, die er zusammenfassen oder auf die er reagieren soll, werden seine Funktionalität und sein Nutzen erheblich beeinträchtigt. Sicherheit ist in diesem Kontext eher als ein Kompromiss zu betrachten und nicht als eine Checkliste, die es zu erfüllen gilt.

Neue Ansätze für mehr Sicherheit

Aufgrund von Risiken durch Prompt-Injection und Agent-Hijacking gibt es derzeit keine vollständig sichere Methode, KI-Agenten mit weitreichenden Berechtigungen zu betreiben, ohne dabei ein gewisses Restrisiko in Kauf zu nehmen. Dennoch lässt sich mit neuen Strategien der potenzielle Schaden begrenzen, falls ein Agent manipuliert oder kompromittiert wird.

So sollte Isolierung höchste Priorität haben. Agenten sollten auf den Einsatz in bestimmten Umgebungen beschränkt werden – wie spezielle Container oder virtuelle Maschinen mit isolierten Benutzerberechtigungen. Wie zuvor erwähnt, ist Sandboxing unerlässlich. Im Rahmen des Projekts Nanoclaw wird beispielsweise eine robuste Sandbox rund um einen Agenten vom Typ OpenClaw entwickelt.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Agentenumgebungen sollten zudem als „potenziell kompromittiert“ behandelt und gemäß Zero-Trust verwaltet werden, was neben Schutzmaßnahmen auch Monitoring, Erkennung und Reaktion umfasst.

Schutz von Vertraulichkeiten

Die Verwaltung von Vertraulichkeiten ist ein weiterer bedeutender Aspekt, insbesondere bei der Verwendung von Agenten für KI-gestütztes Coden. Entwickler verwenden zwar oft kurzlebige, stark eingeschränkte Token, doch auch diese können tiefgreifenden Zugriff auf Produktionssysteme gewähren. Vorsicht gilt es zwingend zu wahren, bevor KI-Coding-Agenten Zugriff gewährt wird.

Es sollte weiterhin ein Secret-Injection-Pattern eingesetzt werden, das sicherstellt, dass der Agent niemals direkten Zugriff auf die Rohdaten bei der Anmeldung hat. Dies verhindert, dass Vertrauliches in Chat-Protokollen oder externen Anfragen offengelegt wird. Derzeit wird an mehreren Tools mit Secret-Injection-Funktionen gearbeitet. Dabei sieht der KI-Agent nur Platzhalter für API-Schlüssel, die tatsächlichen Anmeldedaten werden erst an der Netzwerkgrenze eingefügt.

Risiken innerhalb des erweiterten Ökosystems gilt es ebenfalls zu berücksichtigen. Abhängigkeiten von Drittanbietern sollten beispielsweise als Quelle für Risiken in der Lieferkette behandelt werden. Es ist sicherzustellen, dass Abhängigkeiten nur aus vertrauenswürdigen Quellen stammen. Code, durch den solche Abhängigkeiten entstehen, sollte manuell überprüft werden. Wenn eine Funktion oder ein Plugin nicht zwingend erforderlich ist, sollte keine Installation erfolgen.

Auch der typische Endpunktschutz bleibt unverzichtbar. Angreifer können versuchen, über Prompt-Injection und Agent-Hijacking dauerhaften Zugriff zu erlangen. Daher ist es unerlässlich, standardmäßige Anti-Malware- und Endpunktschutzmaßnahmen auf dem Host zu implementieren und diese Schutzmaßnahmen auf dem neuesten Stand zu halten. Der Einsatz von KI-Agenten erhöht generell den Bedarf an robuster Endpunktsicherheit, anstatt ihn zu verringern.

Die Einführung grundlegender Kontrollmaßnahmen kann das Experimentieren mit KI-Agenten deutlich sicherer machen. Doch selbst mit diesen Schutzmaßnahmen bleiben die Kompromisse bestehen. Jede Aktion, die einem Agenten gewährt wird, stellt einen potenziellen Weg für die Exfiltration von Daten oder für eine böswillige Aktion dar. Solange keine zuverlässigen Schutzmaßnahmen gegen Prompt-Injection und Agent-Hijacking etabliert sind, wird ein Risiko gemanagt, anstatt es zu beseitigen. Letztendlich bleibt ein grundlegender Konflikt bestehen: Je strenger die Einschränkungen, desto geringer der Nutzen des Agenten – und umgekehrt.

Über den Autor: Jim Gumbley ist Business Information Security Officer bei Thoughtworks.

(ID:50925421)