Browser- und Computer-Use-Sandboxen für KI-Agenten: Was isoliert werden sollte

Browser- und Computer-Use-Sandboxen sollten Sitzungen, Dateisystem und Downloads, Anmeldedaten, Cookies, Netzwerkzugriff, Tool-Aktionen, Screenshots und Aufzeichnungen, Logs sowie den Rücksetzungszustand isolieren, damit KI-Agenten beim Bedienen von Webseiten, Anwendungen und Dateien nicht stillschweigend ihre Vertrauensgrenze ausweiten können.

Warum Browser- und Computer-Use-Agenten eine Sandbox benötigen

Browser-Use- und Computer-Use-Agenten unterscheiden sich von gewöhnlichen Chatbots. Sie beantworten nicht nur eine Frage; sie klicken, tippen, laden Dateien herunter, lesen Webseiten, füllen Formulare aus und bedienen manchmal eine vollständige desktopähnliche Umgebung. Das macht die Laufzeit zu einem Teil des Sicherheitsmodells.

Ein reiner Text-Assistent kann eine schlechte Antwort liefern. Ein Browser- oder Computer-Use-Agent kann eine schlechte Aktion ausführen. Er könnte ein Formular absenden, ein Sitzungs-Cookie in ein Log lecken, eine unsichere Datei herunterladen, einen Arbeitsbereich überschreiben, einer in einer Webseite versteckten Prompt Injection folgen oder eine Anmeldeinformation in einem Kontext verwenden, in dem sie nicht verfügbar sein sollte.

Die Sandbox ist der Ort, an dem diese Aktionen eingeschränkt werden. Sie sollte praktische Fragen beantworten wie:

• In welchem Account ist der Browser eingeloggt?
• Welche Dateien kann der Agent lesen oder schreiben?
• Welche Domains kann der Agent kontaktieren?
• Welche Cookies und Tokens bleiben nach der Aufgabe bestehen?
• Welche Klicks, Befehle, Screenshots und Dateiänderungen können später eingesehen werden?
• Was wird zerstört, wenn die Aufgabe endet?

Das Ziel ist nicht, so zu tun, als ob eine Sandbox jedes Risiko beseitigt. Das Ziel ist, die Betriebsumgebung des Agenten eng, beobachtbar und zurücksetzbar zu machen. Wenn ein Modell oder Tool die falsche Entscheidung trifft, sollte der Schaden auf die Sitzung und die Ressourcen begrenzt sein, die Sie absichtlich freigegeben haben.

Was in einer Browser-Sitzung isoliert werden sollte

Beginnen Sie mit dem Browser-Profil. Ein Browser-Agent sollte nicht das tägliche Browser-Profil eines Entwicklers, persönliche Erweiterungen, gespeicherte Passwörter, dauerhafte Cookies oder ein unverwaltetes Download-Verzeichnis verwenden. Geben Sie jeder Aufgabe, jedem Benutzer oder Workflow ein eigenes Profil, es sei denn, es gibt einen bewussten Grund, Zustand zu teilen.

Bewerten Sie mindestens, ob die Sandbox Folgendes trennt:

Grenze	Was ohne sie schiefgehen kann	Was zu prüfen ist
Browser-Profil	Der Agent erbt nicht zugehörige Logins, Erweiterungen, Cookies, Autofill oder Browserverlauf.	Profile pro Aufgabe oder Benutzer, explizite Persistenzregeln, Erweiterungskontrollen.
Sitzungslebenszyklus	Ein vorheriger Aufgabenstatus ändert das Ergebnis der nächsten Aufgabe.	Erstellung neuer Sitzungen, Snapshot-Wiederherstellung, Bereinigung und Ablaufverhalten.
Tabs und Fenster	Der Agent liest oder klickt Inhalte aus dem falschen Kontext.	Tab-Scoping, aktive Fensterverfolgung und Ereignisprotokolle.
Browser-Speicher	LocalStorage, IndexedDB, Cache und Service Worker speichern sensible Zustände.	Speicherzurücksetzung, Exportregeln und bereinigungsregeln pro Domain.
Downloads	Dateien aus dem Web landen in einem gemeinsamen Verzeichnis.	Isolierter Download-Ordner, Dateityp-Richtlinie, bei Bedarf Malware-Scan-Workflow.

Behandeln Sie den Browser als Arbeitsbereich, nicht als wegwerfbaren UI-Wrapper. Moderne Webanwendungen halten wichtige Zustände in Cookies, Local Storage, Caches, Service Workern, Hintergrundanfragen und heruntergeladenen Dateien. Wenn die Sandbox nur ein Browserfenster öffnet, aber nicht definiert, was mit diesem Zustand passiert, ist die Isolationsgrenze unvollständig.

Für Computer-Use-Umgebungen gilt das gleiche Prinzip über den Browser hinaus. Der Agent kann mit einem Terminal, Dateimanager, Dokumenteneditor, lokalem Vorschau-Server oder einer GUI-Anwendung interagieren. Diese Umgebung benötigt ein abgegrenztes Home-Verzeichnis, klare Einhängepunkte und eine Möglichkeit, Aufgabenergebnisse von Laufzeit-Interna zu trennen.

Umgang mit Cookies, Konten und Anmeldedaten

Cookies und eingeloggte Konten sind oft der sensibelste Teil der Browser-Automatisierung. Ein Browser-Agent mit einer gültigen Sitzung kann alles tun, was das Konto erlaubt, selbst wenn das Modell nie das rohe Passwort sieht.

Verwenden Sie wenn möglich ein separates Konto für die Agentenarbeit. Das Konto sollte die minimalen Berechtigungen haben, die für den Workflow nötig sind, und die Sandbox sollte klar machen, ob Cookies injiziert, während des Logins erstellt, zwischen Ausführungen beibehalten oder nach Abschluss zerstört werden.

Der Umgang mit Anmeldedaten benötigt eine strengere Regel: Geben Sie dem Agenten niemals breite Geheimnisse, nur weil eine Website danach fragen könnte. Bevorzugen Sie abgegrenzte, zeitlich begrenzte Tokens; Workflow-spezifische Anmeldedaten; und vermittelte Zugriffe, bei denen der Agent ein schmales Tool aufruft, anstatt ein rohes Geheimnis zu lesen. Wenn ein Geheimnis innerhalb der Sandbox verfügbar sein muss, entscheiden Sie, ob es als Umgebungsvariable, eingehängte Datei, Browser-Anmeldedaten oder nur als Tool-Fähigkeit erscheint.

Achten Sie auf diese Anti-Patterns:

• Ein gemeinsames Browser-Profil mit persönlichen oder Admin-Cookies.
• Geheimnisse, die vom Modell ohne Genehmigung in eine Seite eingefügt werden.
• API-Schlüssel, die für alle Tools in der Sandbox verfügbar sind.
• Sitzungs-Cookies, die in ganzseitigen Screenshots oder Debug-Logs erfasst werden.
• Formular-Autofill, das für Produktionskonten aktiviert ist.
• Langzeit-Anmeldedaten, die in heruntergeladenen Dateien, Shell-Verlauf oder Browser-Speicher hinterlassen werden.

Die OWASP-Leitlinien für LLM-Anwendungen heben Prompt Injection und übermäßige Handlungsfreiheit als wiederkehrende Risiken in agentischen Systemen hervor. Bei Browser-Agenten treffen diese Risiken direkt auf das Web: Eine Seite kann Anweisungen enthalten, die versuchen, das Modell zu beeinflussen, und das Modell kann über Tools verfügen, die echte Aktionen ausführen. Isolation bietet eine zweite Verteidigungslinie, wenn das Befolgen von Anweisungen nicht ausreicht.

Wie Downloads, Dateien und Zwischenablagedaten eingeschlossen werden

Downloads sind eine Vertrauensgrenze. Ein Browser-Agent kann PDFs, Tabellenkalkulationen, Archive, Screenshots, Rechnungen, Build-Artefakte oder ausführbare Dateien speichern. Diese Dateien sollten in einem Verzeichnis landen, das der Sandbox gehört, nicht in einem gemeinsamen Desktop-Ordner oder einem Produktions-Arbeitsbereich.

Eine praktische Download-Richtlinie sollte Folgendes abdecken:

• Erlaubte Dateitypen und maximale Dateigröße.
• Ob heruntergeladene Dateien automatisch geöffnet werden können.
• Ob Dateien auf eine andere Seite hochgeladen werden können.
• Wie Dateien gescannt, gehasht oder protokolliert werden.
• Welche Dateien am Ende des Laufs aus der Sandbox exportiert werden.
• Wie temporäre Dateien gelöscht werden.

Für Computer-Use-Agenten sind Dateigrenzen noch wichtiger, da der Agent im Rahmen der Aufgabe lokale Dateien erstellen oder ändern kann. Ein Code-Agent könnte ein Repository bearbeiten. Ein Daten-Agent könnte Diagramme erstellen. Ein Browser-Agent könnte eine CSV herunterladen, transformieren und ein Ergebnis hochladen. Jeder Pfad sollte explizit sein: wo Eingaben ankommen, wo Arbeitsdateien leben, wo genehmigte Ausgaben exportiert werden und was gelöscht wird.

Der Zwischenablagezugriff verdient eine eigene Entscheidung. Er ist praktisch für die GUI-Automation, kann aber auch sensible Texte zwischen nicht zusammenhängenden Anwendungen verschieben. Wenn der Agent die Zwischenablage lesen kann, könnte er ein Token sehen, das ein Mensch vor Sekunden kopiert hat. Wenn er in die Zwischenablage schreiben kann, könnte dies die nächste Einfügeaktion des Menschen beeinflussen. Machen Sie in sensiblen Workflows den Zwischenablagezugriff sitzungslokal oder erfordern Sie eine explizite Genehmigung vor dem Überschreiten der Mensch-Sandbox-Grenze.

Die Bildschirminteraktion hat ein ähnliches Problem. Computer-Use-Agenten arbeiten mit Screenshots, Accessibility Trees oder gerendertem UI-Zustand. Screenshots können private Daten, Kontonamen, Tokens, Dokumententexte oder Kundendatensätze enthalten. Entscheiden Sie, ob Screenshots aufbewahrt, geschwärzt, an einen Modellanbieter gestreamt oder zur Wiedergabe gespeichert werden. Behandeln Sie sie nicht als harmlose Debug-Bilder.

Wie DOM-Aktionen, Screenshots und Wiedergabespuren protokolliert werden

Eine Browser-Sandbox sollte Aktionen nachvollziehbar machen. Wenn ein Agent auf einen Button klickt oder ein Formular absendet, sollte ein Sicherheitsteam oder Entwickler rekonstruieren können, was passiert ist, ohne aus dem Endergebnis raten zu müssen.

Für die Browser-Automation sind nützliche Logs:

• Besuchte URL und Ursprung.
• DOM-Selektor oder Accessibility-Ziel, das für jede Aktion verwendet wurde.
• Getippter Text mit Schwärzung von Geheimnissen.
• Formular-Absendeereignisse.
• Gestartete und abgeschlossene Downloads.
• Netzwerkanfragen auf Domain- oder Endpunktebene.
• Konsolenfehler und Seitenfehler.
• Screenshot-Checkpoints vor oder nach sensiblen Schritten.

Für die Computer-Use-Automation fügen Sie Tool-Aufrufe, Prozessstarts, Shell-Befehle, Datei-Lese- und Schreibvorgänge, Fensterfokusänderungen und exportierte Artefakte hinzu. Das Log sollte unterscheiden, was das Modell angefordert hat, was die Automatisierungsschicht ausgeführt hat und was die Umgebung zurückgegeben hat. Diese Unterscheidung ist wichtig beim Debuggen von Prompt Injection, flaky UI-Verhalten oder einem Tool-Wrapper-Fehler.

Die Wiedergabe ist hilfreich, aber sie ändert die Frage der Datenaufbewahrung. Eine vollständige Wiedergabespur kann Screenshots, Seitentexte, Formularinhalte, Dateinamen, Terminal-Ausgaben und Anmeldedaten enthalten, es sei denn, die Schwärzung ist integriert. Entscheiden Sie im Voraus, wer auf Wiedergaben zugreifen kann, wie lange sie aufbewahrt werden und ob sensible Werte vor der Speicherung maskiert werden.

Der richtige Detaillierungsgrad hängt vom Workflow ab. Ein öffentlicher Preisüberwachungs-Agent benötigt möglicherweise leichte Logs. Ein Agent, der Kundenkonten, Abrechnungsseiten, Infrastruktur-Konsolen oder interne Tools berührt, benötigt stärkere Prüfpfade und strengere Aufbewahrungskontrollen.

Wie Netzwerk-, Genehmigungs- und Rücksetzungsgrenzen festgelegt werden

Netzwerkzugriff ist ein Bereich, in dem sich eine Browser-Sandbox stillschweigend ausweiten kann. Eine Aufgabe kann mit einer Website beginnen, dann Drittanbieter-Skripte laden, Weiterleitungen folgen, APIs aufrufen, Pakete herunterladen oder interne Domains erreichen. Wenn die Sandbox breiten ausgehenden Zugriff hat, kann der Agent Daten an Orte verschieben, die der Anwendungsbesitzer nicht erwartet hat.

Für Browser- und Computer-Use-Agenten sollten Sie Folgendes in Betracht ziehen:

• Domain-Allowlists für erwartete Webziele.
• Sperren für interne Metadaten-Dienste und private Netzwerkbereiche.
• Separate Richtlinie für Paketregister, Objektspeicher und Websuche.
• DNS-Protokollierung, wo die Sicherheitsüberprüfung dies erfordert.
• Ausgangslogs, die einer Sitzung und Aufgabe zugeordnet werden können.

Die menschliche Genehmigung sollte vor Aktionen sitzen, die schwer rückgängig zu machen oder rechtlich bedeutsam sind. Beispiele sind das Tätigen von Käufen, das Senden von Nachrichten, das Ändern von Kontoeinstellungen, das Löschen von Dateien, das Rotieren von Anmeldedaten, das Einladen von Benutzern, das Öffnen von Support-Tickets oder das Hochladen von Kundendaten. Das Genehmigungsereignis sollte erfassen, was der Agent beabsichtigt, welche Seite oder Datei betroffen ist und welche Aktion genau genehmigt wurde.

Das Rücksetzungsverhalten ist die letzte Grenze. Eine gute Sandbox sollte offensichtlich machen, was passiert, wenn eine Aufgabe endet:

Zustand	Rücksetzungsfrage
Browser-Cookies	Werden sie zerstört, beibehalten oder als Checkpoint gespeichert?
Browser-Speicher	Werden Cache, Local Storage, IndexedDB und Service-Worker-Zustand gelöscht?
Downloads	Werden Dateien gelöscht, zur Überprüfung aufbewahrt oder an einen kontrollierten Ort exportiert?
Anmeldedaten	Werden Tokens widerrufen, rotiert oder aus der Umgebung entfernt?
Logs und Wiedergabe	Was wird aufbewahrt, geschwärzt und für wie lange?
Netzwerkzugriff	Werden temporäre Allowlists oder Proxy-Anmeldedaten entfernt?
Dateisystem	Wird der Arbeitsbereich gelöscht, als Snapshot gespeichert oder wiederverwendet?

Persistente Sitzungen sind nützlich für langlebige Agenten, aber die Persistenz sollte beabsichtigt sein. Wenn ein Browser-Profil, Dateisystem oder Prozesszustand über Läufe hinweg überlebt, dokumentieren Sie, warum er bestehen bleibt und wer ihn zurücksetzen kann.

Wie die Novita Agent Sandbox in diese Bewertung passt

Novita Agent Sandbox ist für den Betrieb von KI-Agent-Workloads in isolierten Cloud-Umgebungen konzipiert. Die Produktseite beschreibt Unterstützung für Code-Ausführung, Browser-Use, Computer-Use, persistente Sitzungen, Live-Sitzungsansicht und wiederverwendbare Vorlagen. Die Schnellstartdokumentation zur Novita Agent Sandbox zeigt, wie Entwickler eine Sandbox erstellen, Befehle ausführen, mit Dateien arbeiten und eine Sandbox über SDKs verwalten können.

Diese Fähigkeiten machen Novita relevant, wenn Sie Browser-Agent-, Code-Agent-, Datenanalyse- und langlebige Agent-Workflows bewerten. Die Bewertung muss dennoch für Ihr Bedrohungsmodell spezifisch sein. Bevor Sie einen Sandbox-Anbieter für sensible Browser- oder Computer-Use-Automation verwenden, bestätigen Sie das genaue Verhalten, das Sie in Bezug auf Browser-Profile, Cookies, Anmeldedateninjektion, Netzwerkabgang, Screenshot-Aufbewahrung, Dateiexport, Logs und Rücksetzungssemantik benötigen.

Für Teams, die bereits Novita AI-Modelle verwenden, liegt der praktische Vorteil in der betrieblichen Passung: Inferenz und Agent-Ausführung können innerhalb derselben Builder-Plattform geplant werden, anstatt als separate Infrastrukturentscheidungen behandelt zu werden. Trennen Sie jedoch Produktbehauptungen von Sicherheitsannahmen. Eine Sandbox kann nützliche Isolation und Lebenszykluskontrollen bieten, aber Ihre Anwendung benötigt dennoch Konten mit minimalen Berechtigungen, abgegrenzte Anmeldedaten, Genehmigungsstufen und Prüfregeln für die Aktionen Ihres Agenten.

Checkliste für Browser- und Computer-Use-Sandboxen

Verwenden Sie diese Checkliste, bevor Sie einem Agenten Zugriff auf eine echte Website, ein Konto oder einen desktopähnlichen Arbeitsbereich gewähren.

Bereich	Bewertungsfrage
Sitzung	Erhält jede Aufgabe ein isoliertes Browser-Profil oder einen isolierten Arbeitsbereich?
Konten	Verwendet der Agent ein Konto mit minimalen Berechtigungen anstelle des Hauptkontos eines Menschen?
Cookies	Sind Cookies abgegrenzt, absichtlich beibehalten und beim Zurücksetzen gelöscht?
Anmeldedaten	Sind Geheimnisse abgegrenzt, zeitlich begrenzt, in Logs geschwärzt und für nicht zusammenhängende Tools nicht verfügbar?
Downloads	Bleiben Dateien in einem Verzeichnis, das der Sandbox gehört, bis sie explizit exportiert werden?
Zwischenablage	Kann der Agent die menschliche Zwischenablage lesen oder schreiben, oder nur eine sitzungslokale Zwischenablage?
Screenshots	Werden Screenshots aufbewahrt, geschwärzt und zugriffskontrolliert?
DOM-Aktionen	Werden Klicks, getippter Text, Formulare, Selektoren und Seitenursprünge protokolliert?
Tool-Aufrufe	Können Sie Modellabsicht von ausgeführter Tool-Aktion trennen?
Netzwerk	Sind Domains, private Bereiche, Paketregister und DNS-Verhalten kontrolliert?
Genehmigung	Welche Aktionen erfordern einen menschlichen Bestätigungsschritt?
Zurücksetzung	Was wird genau gelöscht, aufbewahrt, widerrufen oder als Snapshot gespeichert nach dem Lauf?
Vorfallprüfung	Können Sie aus Logs, Dateien, Netzwerkereignissen und Wiedergabe rekonstruieren, was passiert ist?

FAQ

Was ist der Unterschied zwischen einer Browser-Sandbox und einer Computer-Use-Sandbox?

Eine Browser-Sandbox schränkt ein, was ein Webbrowser tun kann: welche Profile, Cookies und Speicher verfügbar sind, welche Domains der Browser kontaktieren kann und welche Downloads erlaubt sind. Eine Computer-Use-Sandbox ist umfassender und deckt eine vollständige desktopähnliche Umgebung ab – Terminalzugriff, Dateimanager, GUI-Anwendungen und lokale Prozesse zusätzlich zum Browser. Beide teilen die gleichen Kernbedenken hinsichtlich Zurücksetzung, Protokollierung, Anmeldedatenabgrenzung und Konten mit minimalen Berechtigungen, aber Computer-Use-Umgebungen erfordern zusätzliche Entscheidungen zu eingehängten Verzeichnissen, Zwischenablagezugriff, Bildschirmdaten und Prozessisolation.

Benötige ich ein separates Browser-Profil für jede Agentenaufgabe?

In den meisten Fällen ja. Das Teilen eines Profils über Aufgaben hinweg bedeutet, dass eine Aufgabe Cookies, Logins, gespeicherte Passwörter und Browser-Speicher sehen kann, die von einer anderen hinterlassen wurden. Profile pro Aufgabe sind der einfachste Weg, um unbeabsichtigte Zustandsübertragungen zu verhindern. Wenn Ihr Workflow Sitzungspersistenz erfordert – zum Beispiel ein langlebiger Agent, der dort weitermacht, wo er aufgehört hat – machen Sie die Persistenz explizit und dokumentieren Sie genau, welcher Zustand übergeht und warum.

Können KI-Agenten sicher mit Anmeldedaten innerhalb einer Sandbox umgehen?

Anmeldedaten sind innerhalb einer Sandbox sicherer als in einer unkontrollierten Umgebung, aber die Sandbox allein macht den Umgang mit Anmeldedaten nicht sicher. Die Hauptrisiken sind Überbelichtung (dem Agenten mehr Zugriff geben, als die Aufgabe erfordert), Leckage (Anmeldedaten erscheinen in Logs, Screenshots oder Debug-Ausgaben) und Persistenz (Tokens oder Cookies bleiben nach Aufgabenende verfügbar). Bevorzugen Sie abgegrenzte, zeitlich begrenzte Anmeldedaten; vermitteln Sie Zugriff durch schmale Tool-Aufrufe anstatt roher Geheimnisse; und bestätigen Sie, dass Logs und Screenshots sensible Werte vor der Speicherung schwärzen.

Was passiert, wenn ein KI-Agent eine schädliche Datei herunterlädt?

Die Download-Richtlinie der Sandbox bestimmt den Schadensbereich. Wenn Downloads in ein Verzeichnis der Sandbox isoliert sind, das automatische Öffnen deaktiviert ist und Dateityp-Einschränkungen vorhanden sind, kann eine heruntergeladene Datei nicht automatisch ausgeführt werden oder das breitere Dateisystem erreichen. Ohne diese Kontrollen könnte eine schädliche Datei ausgeführt werden, gemeinsame Verzeichnisse erreichen oder anderswo hochgeladen werden, bevor ein Mensch sie überprüft. Behandeln Sie Downloads als potenziell nicht vertrauenswürdige Eingaben und definieren Sie explizite Richtlinien, welche Dateitypen erlaubt sind, ob sie innerhalb der Sandbox geöffnet werden können und wie sie gescannt oder protokolliert werden.

Wie erkenne ich Prompt Injection in einem Browser-Agenten?

Prompt Injection von einer Webseite ist auf Modellebene schwer zuverlässig zu erkennen. Sandboxing ist eine der wichtigsten defensiven Kontrollen, da es einschränkt, was der Agent tun kann, selbst wenn eine schädliche Anweisung befolgt wird. Praktische Signale sind unerwartete Tool-Aufrufe oder Navigationen, Aktionen außerhalb der beabsichtigten Domain, ungewöhnliche Formularübermittlungen und Versuche, Anmeldedaten oder Sitzungsdaten abzurufen oder zu übertragen. Gute DOM-Aktionslogs – die aufzeichnen, welche Seite besucht wurde, welche Selektoren anvisiert wurden und welcher Text getippt wurde – erleichtern die Rekonstruktion, ob eine Seite das Verhalten des Agenten beeinflusst hat.

Bedeutet die Verwendung einer Sandbox, dass mein Agent sicher ist?

Eine Sandbox verkleinert den Schadensbereich, beseitigt das Risiko jedoch nicht. Sie schränkt ein, was der Agent erreichen kann und was einen Reset überlebt, verhindert aber keine schlechten Modellentscheidungen, falsch konfigurierte Anmeldedaten oder anwendungsspezifische Schwachstellen. Sicherheit hängt von mehrschichtigen Kontrollen ab: Konten mit minimalen Berechtigungen, abgegrenzte Anmeldedaten, Genehmigungsstufen für irreversible Aktionen, Prüfprotokolle, die Modellabsicht und ausgeführte Aktionen erfassen, sowie menschliche Überprüfung, bevor sensible Workflows in die Produktion gehen. Eine Sandbox ist eine Schicht, nicht die vollständige Antwort.

Wie lange sollten Screenshots und Wiedergabedaten aufbewahrt werden?

Die Aufbewahrung hängt von der Sensibilität des Workflows und Ihren Prüfanforderungen ab. Für Agenten, die personenbezogene Daten, Abrechnungssysteme, Kundenkonten oder interne Tools berühren, ist ein definiertes Aufbewahrungsfenster mit Zugriffskontrollen und Schwärzung sensibler Werte (Tokens, Formularinhalte, sichtbare Anmeldedaten) eine vernünftige Grundlinie. Für Workflows mit geringer Sensibilität kann eine kürzere Aufbewahrung oder eine reine Zusammenfassungsprotokollierung angemessen sein. Entscheiden Sie vor der Bereitstellung, wer auf Wiedergaben zugreifen kann, wie lange sie aufbewahrt werden und wie sie gelöscht werden. Behandeln Sie Screenshots nicht als harmlose Debug-Artefakte – sie enthalten oft mehr sensible Daten als strukturierte Logs.

Welche Agentenaktionen sollten immer eine menschliche Genehmigung erfordern?

Aktionen, die schwer rückgängig zu machen oder rechtlich bedeutsam sind, sind die klarsten Kandidaten: Käufe, Änderungen von Kontoeinstellungen, Dateilöschungen, Rotation von Anmeldedaten, Benutzereinladungen, Einreichung von Support-Tickets und Uploads von Kunden- oder regulierten Daten. Darüber hinaus sollten Sie eine Genehmigung für jede Aktion außerhalb des ursprünglichen Aufgabenbereichs des Agenten, jede Aktion auf einer zu Beginn des Laufs nicht erwarteten Domain oder Konto sowie jeden Download oder jede Ausführung von Dateien in Betracht ziehen, die die Aufgabe nicht explizit erforderte. Das Genehmigungsereignis sollte aufzeichnen, was der Agent zu tun beabsichtigte und was der Mensch explizit bestätigt hat.

Empfohlene Artikel

• How Agent Sandboxes Power Secure, Scalable AI Innovation
• Build a Remote Code Execution MCP Server with Novita Sandbox and mcp-use Library
• Host Clawdbot (OpenClaw) with Novita Sandbox Template: Complete Guide