Ausgangslage
Ich habe ein paar wiederkehrende, automatisierte Tasks eingerichtet, die im Hintergrund Webseiten abrufen und mir die Ergebnisse als Kurzbericht zusammenfassen. Praktisch, aber es handelt sich technisch um einen KI-Agenten mit Internetzugriff, der Inhalte liest, die ich nicht kontrolliere.
Problem
Mir war unklar, wie ich das Sicherheitsrisiko einschätzen soll. Konkret ging es um Prompt Injection: die Möglichkeit, dass eine Webseite versteckte Anweisungen enthält, die den Agenten dazu bringen, statt der eigentlichen Aufgabe etwas anderes zu tun. Da ich mit dieser Art von Automatisierung noch keine Erfahrung hatte, war für mich schwer greifbar, ob das ein theoretisches oder ein reales Problem ist – und ob es sinnvoll wäre, solche Tasks auf ein separates Konto oder ein separates System (z. B. eine selbstgehostete Automatisierungsplattform) auszulagern, um das Risiko zu reduzieren. Zusätzlich stellte sich die Frage, ob eine erfolgreiche Injection über den einzelnen Task hinaus Schaden anrichten könnte – etwa durch Zugriff auf andere, unabhängige Arbeitsbereiche desselben Kontos.
Auflösung
Die entscheidende Erkenntnis: der Anbieter des Agenten ist zweitrangig. Prompt Injection ist kein produktspezifisches Problem, sondern eine grundsätzliche Eigenschaft jedes Systems, das unvertrauenswürdige Webinhalte in einen Sprachmodell-Kontext lädt. Ein Wechsel auf ein anderes Konto oder einen anderen Anbieter reduziert nicht die Wahrscheinlichkeit eines Injection-Versuchs, sondern höchstens den Schaden im Erfolgsfall.
Massgeblich ist eine einzige Frage, die sich eins zu eins auf mein Netzwerk-Segmentierungsprinzip übertragen lässt: Kann der Task nur Informationen lesen und berichten, oder kann er auch etwas tun (Dateien verändern, Nachrichten verschicken, auf andere Dienste zugreifen)? Ein erfolgreicher Angriff braucht beides gleichzeitig – Zugriff auf unvertrauenswürdige Inhalte und die Fähigkeit, daraus eine Handlung abzuleiten. Fehlt die Handlungsfähigkeit, bleibt im schlimmsten Fall ein falscher oder manipulierter Bericht, aber keine reale Aktion.
Zusätzlich zeigte sich beim genaueren Hinschauen, dass separate Arbeitsbereiche innerhalb desselben Kontos ohnehin bereits voneinander isoliert sind: Was ein Task in einem Arbeitsbereich verarbeitet oder sich merkt, bleibt dort und fliesst nicht in andere Arbeitsbereiche oder normale Unterhaltungen über. Ein einzelner Task läuft als eigene, abgeschlossene Session ohne Lesezugriff auf andere Bereiche desselben Kontos, solange kein gemeinsamer Kontext (z. B. eine geteilte Datei oder ein geteilter Dienst) explizit eingerichtet wurde. Eine erfolgreiche Injection bleibt damit strukturell auf den betroffenen Task begrenzt und kann nicht seitwärts auf andere Arbeitsbereiche übergreifen.
Für meine aktuellen Tasks gilt: sie lesen nur und liefern eine Zusammenfassung, ohne Zugriff auf Dateien, E-Mail oder andere Dienste, und ohne geteilten Kontext mit anderen Arbeitsbereichen. Der Blast Radius ist damit von Haus aus klein. Eine Auslagerung auf ein separates Konto hätte daran wenig geändert, da die zugrunde liegende Angreifbarkeit dieselbe bleibt. Eine strukturell sauberere Variante wäre eine selbstgehostete Automatisierungsplattform mit einer deterministischen Pipeline (Abruf → Filter → reine Zusammenfassung ohne Werkzeugzugriff) gewesen – dort ist die Handlungsfähigkeit technisch auf null reduziert, nicht nur organisatorisch. Für den aktuellen Anwendungsfall war mir der Zusatzaufwand dafür aber nicht verhältnismässig, da bereits jetzt keine Handlungsfähigkeit besteht.
Lessons Learned
- Prompt Injection ist ein systemisches Risiko, kein Anbieter-spezifisches – ein Kontowechsel allein löst das Grundproblem nicht
- Die relevante Frage ist immer: Lesen oder Handeln? Solange ein Agent nur berichtet, bleibt der Schaden im Fall einer erfolgreichen Injection begrenzt
- Getrennte Arbeitsbereiche innerhalb desselben Kontos sind bereits standardmässig voneinander isoliert – eine Injection in einem Task kann nicht ohne Weiteres auf andere Bereiche übergreifen
- Das aus der Netzwerksegmentierung bekannte Blast-Radius-Denken lässt sich direkt auf KI-Agenten übertragen: nicht „wem vertraue ich“, sondern „was kann im Schadensfall maximal passieren“
- Sobald ein Task zusätzliche Handlungsfähigkeit erhält (weitere Systemzugriffe, Aktionen mit Aussenwirkung), muss die Risikobewertung neu gemacht werden
Fazit
Für reine Lese- und Report-Tasks ist das Risiko überschaubar, solange keine Handlungsfähigkeit dazukommt und die Arbeitsbereiche voneinander isoliert bleiben. Eine Auslagerung auf ein separates Konto oder System lohnt sich erst, wenn der Task mehr können soll als Informationen zusammenzufassen – dann aber eher in Richtung einer selbstgehosteten, deterministischen Lösung ohne Werkzeugzugriff als in Richtung eines zweiten Anbieter-Kontos.