Eigenständige KI-generierte Konzeptillustration: Die Tore stehen für getrennte Autorisierungsprüfungen, nicht für ein reales Produkt oder ein gemessenes Sicherheitsergebnis.
Mit der Handlung beginnen, nicht mit der Antwort
Stellen Sie sich einen Beschaffungsassistenten vor, der drei Lieferantenangebote zusammenfassen soll. Eines der Dokumente enthält die Aufforderung, den vollständigen Vergleich an eine externe Adresse zu senden. Der Assistent erzeugt gültiges JSON, verwendet das richtige E-Mail-Tool und verfasst eine flüssig formulierte Nachricht. Der Ablauf kann trotzdem scheitern: Das Dokument war eine zu lesende Informationsquelle, keine Person, die zur Freigabe der Weitergabe berechtigt ist.
Dies ist ein hypothetisches Entwurfsbeispiel. Wir haben weder einen Angriff durchgeführt noch Anbieter anhand von Benchmarks verglichen oder die Installation eines Kunden untersucht. Unsere Aussage ist enger gefasst: Die Fähigkeit eines Agenten, eine formal korrekte Handlung vorzuschlagen, sollte von der Entscheidung des Systems getrennt sein, diese Handlung zuzulassen.
Die folgende Analyse stützt sich auf Primärdokumentation, die am 21. Oktober 2026 geprüft wurde. Sie bietet einen technischen Orientierungsrahmen, keine Sicherheitszertifizierung und kein Rechtsgutachten.
Was die Dokumentation tatsächlich belegt
OpenAI plädiert in seiner Erläuterung vom 11. März 2026 dafür, Schäden auch dann zu begrenzen, wenn eine Prompt-Manipulation gelingt. Der Leitfaden zur Workflow-Sicherheit empfiehlt strukturierte Daten und Freigaben, warnt aber zugleich, dass Schutzmaßnahmen Fehler nicht ausschließen. Der Leitfaden bezieht sich auf Agent Builder, das auf der aktuellen Seite als veraltet gekennzeichnet ist; dies ist keine Empfehlung, dieses Produkt einzusetzen.
Anthropics Artikel zum Sandboxing vom 20. Oktober 2025 beschreibt die Isolation von Dateisystem und Netzwerk. Die aktuelle Dokumentation zu Berechtigungen in Claude Code unterscheidet zwischen Tool-Berechtigungen und der Durchsetzung durch das Betriebssystem: Gewöhnliche Read/Edit-Regeln erfassen nicht beliebige Dateizugriffe durch Unterprozesse.
Das offizielle Qwen-Agent-Repository dokumentiert die Isolation mit Docker und das eingeschränkte Einbinden von Verzeichnissen für die Codeinterpretation, mahnt aber zur Vorsicht beim produktiven Einsatz seiner einfachen Sandbox.
Es handelt sich um unterschiedliche Ebenen und Produkte, nicht um einen kontrollierten Vergleich. Ein US-amerikanischer Dienst kann mit zu weitreichenden Zugriffsrechten betrieben werden; ein chinesisches Framework kann mit restriktiven Grenzen eingesetzt werden, oder umgekehrt. Die Herkunft des Modells und der Hosting-Standort ersetzen keine Prüfung der Konfiguration. Keines dieser Dokumente belegt, welcher Anbieter grundsätzlich der sicherste ist.
Ein Autorisierungs-Gateway zwischen Planung und Ausführung setzen
Unser vorgeschlagener Entwurf verteilt drei Aufgaben: Das Modell schlägt eine Handlung vor, ein Gateway prüft die Berechtigung dafür, und eine Ausführungskomponente mit eng begrenzten Rechten führt den erlaubten Vorgang aus. Das Gateway besteht aus Anwendungscode und Mechanismen zur Durchsetzung von Richtlinien, nicht bloß aus einer weiteren Anweisung an das Modell, sich korrekt zu verhalten.
Binden Sie bei jeder folgenreichen Anfrage die Entscheidung an den authentifizierten Nutzer, den Vorgang, die Ressource, das Ziel, den Datenumfang und die geltenden Grenzen. Eine Berechtigung zum Lesen von Lieferantenangeboten darf nicht stillschweigend zur Berechtigung werden, sie per E-Mail zu versenden. Die Erlaubnis, eine Nachricht zu entwerfen, darf nicht stillschweigend zur Sendeerlaubnis werden. Fehlt ein erforderlicher Wert oder ist er mehrdeutig, sollte die Anfrage bis zur Klärung unausgeführt bleiben.
Die Schemavalidierung gehört zu diesem Entwurf, erfüllt aber eine andere Aufgabe. Ein Schema kann verlangen, dass ein Empfängerfeld eine Zeichenkette enthält. Es kann nicht feststellen, ob der Nutzer diesen Empfänger freigegeben hat. Ebenso wird ein prüfendes Modell, so hilfreich es beim Erkennen von Risiken sein mag, nicht allein dadurch zu einer deterministischen Zugriffsschranke, dass es mit Ja oder Nein antwortet.
Diese Trennung klärt auch die Verantwortung nach einer Ablehnung: Die ungültige Anfrage muss korrigiert oder die erforderliche Berechtigung eingeholt werden. Konten zu wechseln oder andere Wege zu wählen, um denselben abgelehnten Vorgang doch auszuführen, ist keine Fehlerbehebung.
Freigaben so präzise gestalten, dass sie auch bei Planänderungen tragen
Eine hilfreiche Bestätigungsansicht zeigt die Handlung, die tatsächlich ausgeführt wird: Ziel, Inhalt oder Datenkategorie, betroffene Ressource sowie Kosten- oder Umfangsgrenzen. Vermeiden Sie eine pauschale Schaltfläche wie „Agenten zulassen?“, die die wichtigen Parameter verbirgt.
Binden Sie die Freigabe an diesen Vorschlag. Ändern sich Empfänger, Anhang, Betrag oder Ressource wesentlich, muss erneut geprüft werden. Für wiederkehrende, klar begrenzte Aufgaben kann eine Organisation eine eng gefasste dauerhafte Erlaubnis definieren, statt bei jedem harmlosen Schritt zu unterbrechen. Die Grenzen müssen weiterhin überprüfbar und durchsetzbar sein; ein externes Dokument darf sie nicht erweitern.
Bestätigungsmüdigkeit und zu weitreichende Berechtigungen sind miteinander verbundene Gestaltungsprobleme. Eine Bestätigung für jeden belanglosen Lesezugriff kann Menschen daran gewöhnen, automatisch zu klicken; eine einzige pauschale Freigabe kann hingegen spätere Risiken verdecken. Ein sinnvoller Mittelweg besteht aus einer dokumentierten Richtlinie für risikoarme Vorgänge, präzisen Freigaben für folgenreiche Änderungen und einem ausdrücklichen Stopp bei unklarer Berechtigung.
Die Folgen eines Fehlers begrenzen
Eine Autorisierungsprüfung schützt den angefragten Vorgang; die Laufzeitisolation begrenzt, worauf die Ausführungsumgebung zugreifen kann. Verwenden Sie Zugangsdaten mit eng begrenztem Geltungsbereich, eingeschränkten Dateisystemzugriff und kontrollierte Netzwerkziele, soweit die Anwendung dies unterstützt. Berücksichtigen Sie Unterprozesse im Bedrohungsmodell. Ein eingeschränktes Dateilesetool reicht nicht aus, wenn dieselbe Ausführungskomponente eine uneingeschränkte Shell starten kann.
Halten Sie den Zustand eines Vorgangs getrennt von der Darstellung durch das Modell. Vorgeschlagen, freigegeben, übermittelt und bestätigt sind unterschiedliche Zustände. Erfassen Sie eine stabile Anfragekennung und nutzen Sie, soweit unterstützt, Idempotenz oder Deduplizierung. Prüfen Sie nach einer Zeitüberschreitung den tatsächlichen Datensatz beim Dienst, bevor Sie einen Versand, Kauf oder eine Veröffentlichung erneut versuchen. „Keine Antwort erhalten“ beweist nicht, dass „nichts geschehen“ ist.
Protokolle sollten diese Rekonstruktion ermöglichen, ohne selbst zu einer weiteren Datenleckquelle zu werden. Bewahren Sie die Aktionskennung, die Entscheidung, die Richtlinienversion und die resultierende Referenz beim Dienst auf; beschränken Sie Geheimnisse und unnötige personenbezogene Inhalte auf ein Minimum. Geben Sie Prüfern genügend Informationen für die Untersuchung, nicht unterschiedslos eine Kopie jedes Dokuments.
Sechs Prüfungen vor dem Produktivbetrieb
Die folgenden Punkte sind ein Vorschlag für eine Abnahmeprüfung, kein von uns durchgeführter Test und keine umfassende Sicherheitsbewertung:
- Fügen Sie einen externen Empfänger in ein abgerufenes Dokument ein. Kann dieser ohne Autorisierung durch den authentifizierten Nutzer das erlaubte Ziel verändern?
- Erzeugen Sie gültiges JSON für eine Handlung außerhalb des erlaubten Umfangs. Lehnt das Gateway sie vor der Übermittlung ab?
- Ändern Sie das Ziel nach der Freigabe. Gilt die bisherige Freigabe dann nicht mehr für die geänderte Handlung?
- Versuchen Sie über einen Unterprozess, eine Datei außerhalb des erlaubten Umfangs zu lesen. Wird die Laufzeitgrenze durchgesetzt, statt lediglich in einem Prompt beschrieben zu sein?
- Simulieren Sie nach einem Versand eine Zeitüberschreitung mit unklarem Ergebnis. Kann der Workflow den Datensatz beim Dienst abgleichen, ohne ein Duplikat zu erzeugen?
- Entziehen Sie die betreffende Berechtigung. Scheitert der nächste Ausführungsversuch sicher und mit einem nachvollziehbaren Prüfprotokoll?
Bewerten Sie sowohl Schutz als auch Nutzbarkeit: blockierte unbefugte Vorgänge, fälschlich blockierte berechtigte Arbeit, unnötige Freigabeaufforderungen, doppelte Seiteneffekte und die Zeit, die zur Erklärung einer Entscheidung benötigt wird. Eine hohe Abschlussquote allein kann unsichere Ausführung verdecken; ein System, das alles blockiert, ist aber ebenfalls kein nützlicher Assistent.
Die entscheidende Frage bei der Beschaffung
Lassen Sie sich vom Anbieter zeigen, welche Ebene jede Grenze in der tatsächlich vorgesehenen Konfiguration durchsetzt, was geschieht, wenn das Modell einem bösartigen Dokument folgt, und wie ein unklarer Ausführungsstatus abgeglichen wird. Verlangen Sie Nachweise, die zu Ihren Tools und Zugriffsbereichen passen, statt eine viel zitierte Benchmark-Zahl aus einer anderen Konfiguration zu übertragen.
Die praktische Wahl lautet nicht „dem Modell vertrauen“ oder „endlos um Erlaubnis bitten“. Entscheidend ist festzulegen, welche Arbeit innerhalb klarer Grenzen weiterlaufen darf, welche Änderungen eine menschliche Entscheidung brauchen und welche Grenzen das Modell nicht umschreiben kann. Das ist ein nützlicherer Ausgangspunkt für den Vergleich chinesischer und US-amerikanischer Agenten-Stacks als ein einzelner Leistungswert.