2026: Wie richten Sie eine isolierte Testumgebung für Claude Computer Use ein?

Die Kurzentscheidung: erst isolieren, dann ausführen

Anthropic beschreibt Computer Use als Werkzeug, dessen Aktionen in einer vom Entwickler kontrollierten Umgebung ausgeführt werden: Der Client empfängt einen Werkzeugaufruf, führt die Aktion aus und sendet das Ergebnis zurück. Die Dokumentation zum Umgang mit Werkzeugaufrufen macht diesen Ablauf zum entscheidenden Sicherheits- und Architekturpunkt. Richten Sie Claude Computer Use deshalb in einer isolierten, niedrig privilegierten Testumgebung ein und trennen Sie Testkonto, erlaubte Websites und menschliche Freigaben. Geht es nur um Inhalte innerhalb eines Browsers, prüfen Sie zuerst Browser Use. Ein vollständiger Desktop ist erst nötig, wenn Ihre Aufgabe tatsächlich Maus, Tastatur oder eine Desktop-Anwendung erfordert.

Für Sie relevant: Entwickeln Sie einen Agenten mit der Claude API, prüfen Sie hier die Verbindung zwischen Werkzeugaufruf und kontrolliertem Client.
Verantworten Sie Desktop-Automatisierungstests, finden Sie Vorgehensweisen zur Trennung von Testkonten und echten Daten.
Leiten Sie einen internen Versuch, sehen Sie, wie Sie sensible Aktionen vor der Ausführung an eine Person binden.

Ihr Wochenplan: Klären Sie zunächst, ob der Test den Browser verlassen muss. Erstellen Sie danach eine isolierte Umgebung mit einem eigens dafür vorgesehenen Konto. Lassen Sie zuerst nur ungefährliche Aktionen zu und ergänzen Sie Freigaben, bevor der Agent etwas abschickt, löscht oder ändert.

Vor dem Aufbau: den tatsächlichen Umfang festlegen

Bevor Sie eine virtuelle Maschine bereitstellen oder einen Container konfigurieren, schreiben Sie den Testablauf als kurze Folge konkreter Aufgaben auf. „Öffnen Sie eine Seite und lesen Sie einen sichtbaren Status ab“ ist etwas anderes als „Starten Sie eine Anwendung, wechseln Sie zwischen Fenstern und bearbeiten Sie eine lokale Datei“. Diese Abgrenzung entscheidet über die erforderliche Umgebung und deren Angriffsfläche.

Claude Computer Use ist für die Interaktion mit einer Computeroberfläche gedacht. Der Agent kann eine Oberfläche anhand von Screenshots auswerten und Aktionen wie Klicken oder Tastatureingaben anfordern. Die Ausführung übernimmt dabei Ihr Client, nicht ein automatisch abgeschirmter persönlicher Rechner. Die offizielle Übersicht zum Computer-Use-Werkzeug beschreibt die verfügbaren Werkzeugfunktionen; die konkrete Unterstützung hängt von den aktuell dokumentierten Modellen und Werkzeugversionen ab. Prüfen Sie diese vor einem neuen Testlauf erneut, statt sich auf eine ältere Implementierung zu verlassen.

Browser Use ist eine andere Option, wenn die Aufgabe auf Webinhalte und Browseraktionen begrenzt bleibt. Es kann den zusätzlichen Desktop-Zugriff vermeiden, den Sie für Anwendungen außerhalb des Browsers benötigen würden. Die Dokumentation zu Browser Use hilft bei der Abgrenzung. Die Werkzeugkombinationen erläutert Anthropic zudem in der Dokumentation zur Kombination von Werkzeugen.

Stellen Sie sich vor dem Aufbau diese Fragen:

• Muss der Agent eine native Anwendung, ein lokales Fenster oder mehrere Desktop-Fenster bedienen? Dann spricht der Arbeitsablauf für Computer Use.
• Findet die gesamte Aufgabe im Browser statt? Dann prüfen Sie zuerst Browser Use.
• Muss eine Datei bearbeitet werden? Legen Sie genau fest, welches Testverzeichnis dafür vorgesehen ist. Geben Sie nicht pauschal das Benutzerverzeichnis frei.
• Muss der Agent eine Änderung absenden oder ein Konto umstellen? Planen Sie eine menschliche Freigabe ein, bevor Sie den Ablauf automatisieren.

Wer kontrolliert die Ausführungsumgebung?

Die Kontrolle liegt bei dem Team, das den Client und die Umgebung betreibt. Claude fordert Werkzeugaktionen an; Ihre Implementierung entscheidet, ob sie ausgeführt werden, auf welchem System sie stattfinden und welche Ergebnisse zurückgesendet werden. Die Übersicht zu Claude-Werkzeugaufrufen erläutert diese Trennung zwischen Modellantwort und lokaler Werkzeugausführung.

Das ist praktisch, bedeutet aber auch: Die Verantwortung lässt sich nicht an den Modellaufruf delegieren. Kontrollieren Sie Container- oder VM-Konfiguration, Sitzung, Dateien, Netzwerkverbindungen und den Umgang mit Werkzeugergebnissen. Ein gut formulierter Systemhinweis ersetzt keine technische Beschränkung. Wenn der Client Zugriff auf ein Verzeichnis oder eine Website hat, kann eine bloße Anweisung an den Agenten diesen Zugriff nicht verlässlich verhindern.

Die Umgebung wählen: Browser, Container, virtuelle Maschine oder Mac

Setzen Sie die kleinste Umgebung ein, die den Test tatsächlich abdeckt. Ein Container kann für isolierte Prozesse nützlich sein, bietet aber nicht automatisch dieselbe Desktop-Erfahrung wie eine virtuelle Maschine mit grafischer Oberfläche. Umgekehrt verursacht ein vollständiger Desktop mehr Konfigurations- und Wartungsaufwand, wenn der Test nur eine Browseransicht benötigt. Entscheidend ist nicht, welches System am leistungsfähigsten wirkt, sondern welches die benötigte Oberfläche kontrolliert bereitstellt.

Eine virtuelle Maschine oder ein Container ist kein absolutes Sicherheitsversprechen. Netzwerkfreigaben, eingehängte Verzeichnisse, gespeicherte Sitzungstoken und Fernzugriffsrechte können die Trennung wieder aufheben. Behandeln Sie die Isolation daher als Risikominderung, die Sie testen und warten müssen.

Bei einer Cloud-Mac-Umgebung sollten Sie vorab festhalten, welche macOS-Anwendung geprüft wird, wie Sie den Bildschirmzugriff erhalten und wie Testdaten nach dem Lauf entfernt werden. Prüfen Sie auch, ob Ihre Richtlinien zur Datenverarbeitung und zur DSGVO mit dem vorgesehenen Ablauf vereinbar sind. Informationen zur Plattform und ein direkter Kontakt für Rückfragen finden Sie auf der VPSSpark-Überblicksseite und über den VPSSpark-Kontakt. Nutzen Sie diese Seiten, um Bedingungen zu klären, nicht als Ersatz für eine technische Sicherheitsprüfung.

Beim Einrichten: Identitäten, Dateien und Netzwerk trennen

Der Agent sollte für einen Test nicht mit Ihren normalen Arbeitskonten oder Produktionszugängen laufen. Richten Sie ein eigenes Testkonto mit den Rechten ein, die der konkrete Ablauf benötigt. Verwenden Sie nach Möglichkeit Beispielinhalte oder synthetische Datensätze. Echte Kundendaten bringen für einen UI-Test ein zusätzliches Datenschutzrisiko mit sich und sind selten erforderlich, um Klickpfade oder Statusanzeigen zu überprüfen.

Wie begrenzen Sie den Zugriff auf vertrauliche Dateien und Websites?

Setzen Sie die Begrenzung an der Umgebung durch, nicht nur in der Beschreibung der Aufgabe. Erteilen Sie Zugriff ausschließlich auf das für den Test vorgesehene Verzeichnis. Vermeiden Sie gemeinsame Laufwerke, private Dokumentordner und dauerhaft eingehängte Produktionsverzeichnisse. Wenn das Betriebssystem oder die Laufzeit Berechtigungen für einzelne Verzeichnisse unterstützt, kontrollieren Sie diese mit einem separaten Testbenutzer.

Für das Netzwerk gilt dasselbe Prinzip: Legen Sie fest, welche Ziele der Test erreichen darf. Wenn Ihr Szenario nur eine interne Testanwendung benötigt, braucht der Agent nicht zugleich freien Zugang zu beliebigen Websites. Ein eingeschränkter Ausgehverkehr hilft, versehentliche Besuche echter Konten und unnötige Datenübertragungen zu vermeiden. Prüfen Sie, welche Verbindungen Ihr Client für den Test braucht, und dokumentieren Sie Ausnahmen.

Behandeln Sie API-Schlüssel als Geheimnisse. Speichern Sie sie nicht in Screenshots, Testdateien oder Protokollen, die weitergegeben werden. Die Anthropic-Dokumentation zu Authentifizierung und API-Schlüsseln beschreibt den Umgang mit Zugangsdaten. Geben Sie einem Testprozess nur die erforderlichen Schlüssel und entfernen Sie sie, sobald der Ablauf beendet ist. Das gilt auch für Anmeldedaten innerhalb der Testanwendung: Legen Sie fest, wer sie erzeugt, wo sie gespeichert werden und wann sie widerrufen oder erneuert werden.

Ein vollständiger Desktop vergrößert die Zahl der möglichen Berührungspunkte. Neben Browserdaten können dort Benachrichtigungen, Zwischenablageinhalte, lokale Dateien oder andere angemeldete Anwendungen sichtbar sein. Bereiten Sie deshalb ein sauberes Testprofil vor. Deaktivieren Sie nicht benötigte Anwendungen und Konten, leeren Sie die Zwischenablage vor der Sitzung und vermeiden Sie private Benachrichtigungen auf dem Testbildschirm.

Beim ersten Lauf: den Aktionskreislauf kontrollieren

Der grundlegende Ablauf hat drei Teile: Claude fordert eine Werkzeugaktion an, Ihr Client führt sie in der ausgewählten Umgebung aus, und der Client sendet das Resultat zurück. Die Beschreibung zur Verarbeitung von Werkzeugaufrufen erläutert diese Übergabe. Prüfen Sie jeden Teil getrennt: Wurde der erwartete Aufruf erzeugt? Hat der Client die richtige Aktion an die richtige Oberfläche gesendet? Beschreibt das zurückgegebene Ergebnis den tatsächlichen Zustand?

Beginnen Sie auf einer ungefährlichen Testseite oder in einer eigens dafür vorgesehenen Anwendung. Lassen Sie den Agenten zunächst eine sichtbare Information suchen oder eine harmlose Navigation ausführen. Vergleichen Sie Screenshot und tatsächlich angezeigte Seite mit dem erwarteten Ergebnis. Ein Klick kann technisch ausgeführt worden sein, obwohl ein Dialog, ein Hinweisfenster oder eine veränderte Oberfläche dazu geführt hat, dass er ein anderes Ziel getroffen hat.

Achten Sie besonders auf diese Fehlerbilder:

• Falsches Ziel: Der Screenshot zeigt eine veränderte oder verschobene Oberfläche. Prüfen Sie den aktuellen Zustand, bevor Sie den nächsten Klick zulassen.
• Veralteter Zustand: Der Client verarbeitet eine Aktion, obwohl die Seite noch lädt oder ein Dialog offen ist. Warten Sie auf einen eindeutig erkennbaren Zustand, bevor Sie das Ergebnis bewerten.
• Unvollständige Rückmeldung: Der Client sendet kein verwertbares Resultat zurück. Kennzeichnen Sie den Lauf als unklar, statt automatisch dieselbe Aktion zu wiederholen.
• Abweichende Anmeldung: Das Testkonto ist abgelaufen oder nicht wie vorgesehen angemeldet. Unterbrechen Sie den Lauf und korrigieren Sie das Konto außerhalb des Agentenablaufs.

Dokumentieren Sie pro Testfall, welches sichtbare Ergebnis Sie erwarten und woran Sie den Erfolg erkennen. Für einen Statuswechsel reicht „der Agent hat auf die Schaltfläche geklickt“ nicht aus. Prüfen Sie, ob die Oberfläche den neuen Status tatsächlich anzeigt und ob ein erneuter Aufruf nicht unbeabsichtigt dieselbe Änderung auslöst.

Bei der Abnahme: irreversible Aktionen abfangen

Trennen Sie Beobachten und Ändern. Ein Test, der eine Seite öffnet oder einen Wert ausliest, ist nicht gleich riskant wie das Absenden eines Formulars, das Löschen einer Datei oder das Ändern von Kontorechten. Für Aktionen mit Auswirkungen auf andere Personen, Geld oder dauerhafte Daten sollte der Client vor der Ausführung anhalten und eine verantwortliche Person um Bestätigung bitten.

Gestalten Sie die Freigabe so, dass klar ist, was bestätigt wird. Zeigen Sie der prüfenden Person die beabsichtigte Aktion, das betroffene Testkonto und den erkannten Zielzustand. Eine pauschale Zustimmung zum gesamten Agentenlauf erschwert die Kontrolle. Bei Testaufgaben mit mehreren Änderungen ist eine Freigabe unmittelbar vor der jeweiligen kritischen Aktion nachvollziehbarer.

Planen Sie außerdem Fehlerwiederherstellung ein. Nach einer unterbrochenen Sitzung darf der Agent nicht automatisch annehmen, dass eine Aktion fehlgeschlagen ist. Prüfen Sie zunächst, ob der Auftrag teilweise ausgeführt wurde. Ein Formular kann bereits übermittelt, eine Datei schon verändert oder eine Sitzung trotz fehlender Rückmeldung weitergelaufen sein. Erst wenn der aktuelle Zustand geklärt ist, entscheiden Sie, ob ein erneuter Versuch sinnvoll ist.

Halten Sie für jedes Szenario fest, wie Sie mit folgenden Fällen umgehen:

• Der Client verliert die Verbindung, nachdem eine Aktion gesendet wurde.
• Eine Anwendung zeigt eine Fehlermeldung, aber der Zustand ist nicht eindeutig.
• Das Testkonto wird gesperrt oder abgemeldet.
• Eine Berechtigung wird abgelehnt oder eine Seite liegt außerhalb des vorgesehenen Umfangs.
• Die Umgebung muss zurückgesetzt werden, bevor ein weiterer Testlauf beginnt.

Diese Aufzeichnungen helfen QA und Entwicklung, Fehler von Berechtigungsproblemen und unvollständigen Ergebnissen zu unterscheiden. Sie schaffen außerdem eine nachvollziehbare Grundlage für die Frage, ob ein Test in der aktuellen Umgebung überhaupt sicher wiederholt werden kann.

Im laufenden Betrieb: Änderungen erneut prüfen

Ein funktionierender Prototyp ist keine dauerhaft geprüfte Integration. Halten Sie fest, welches Modell, welche Werkzeugversion, welcher Client und welche Berechtigungsregeln für einen Testlauf verwendet wurden. Wenn sich unterstützte Modelle, Werkzeugversionen oder API-Verhalten ändern, führen Sie die zentralen Tests erneut aus. Die maßgebliche Referenz ist die jeweils aktuelle Dokumentation zu Computer Use, nicht eine unveränderte Kopie aus einem früheren Projektstand.

Erneuern Sie Testzugänge nach Ihren internen Vorgaben und entfernen Sie nicht mehr benötigte Konten, Schlüssel, Sitzungen und Dateien. Protokolle sollten genug Informationen enthalten, um einen Fehler zu untersuchen, aber keine Passwörter, privaten Inhalte oder unnötigen personenbezogenen Daten. Legen Sie fest, wer die Protokolle sehen darf und wann sie gelöscht werden.

Bewerten Sie bei jeder Änderung erneut, ob Ihr Test weiterhin einen vollständigen Desktop erfordert. Vielleicht wurde ein Ablauf inzwischen in einen Browsertest überführt; möglicherweise muss eine neue macOS-Anwendung tatsächlich auf einer macOS-Oberfläche geprüft werden. So vermeiden Sie, dass eine aufwendigere Umgebung nur aus Gewohnheit weiterläuft.

Am Ende entscheiden: Browser behalten oder vollständigen Desktop nutzen

Die Auswahl lässt sich an Ihrem tatsächlichen Testumfang festmachen. Bleibt der Ablauf im Browser, vermeiden Sie zusätzliche Desktop-Rechte und halten Sie die Ausführungsumgebung so klein wie möglich. Muss der Agent eine native macOS-Oberfläche bedienen, ist ein vollständiger Desktop eine sachgerechte Kandidatenlösung. Wählen Sie zwischen lokaler virtueller Maschine, Container und Cloud-Mac nach Oberfläche, Zugriffskontrolle, Datenrichtlinie und Wiederherstellbarkeit – nicht nach einer pauschalen Annahme, eine Option sei grundsätzlich sicher.

Vergleichen Sie Ihre derzeitige Lösung ehrlich mit einem Mac-Testsystem. Ein gemeinsam genutzter Arbeitsrechner kann private Dateien, Benachrichtigungen und echte Konten in die Automatisierung einbeziehen. Eine selbst verwaltete VM verlangt Pflege von Betriebssystem, Sitzungen und Rücksetzprozessen. Eine reine Browserlösung kann an der Grenze scheitern, sobald ein Test eine native macOS-Anwendung verlangt.

Wenn Sie eine macOS-Oberfläche nur für einen abgegrenzten Testzeitraum benötigen, kann die Miete einer Mac-Umgebung über VPSSpark eine Alternative zur sofortigen Gerätebeschaffung sein. Prüfen Sie vorab, ob Zugriffsweg und Umgebung zu Ihrem Testfall passen; bei langfristiger, dauerhaft hoher Auslastung oder erforderlichen physischen Anschlüssen kann ein eigenes Gerät sinnvoller sein. Für reine Browserabläufe bleibt eine kleinere isolierte Lösung meist die passendere Wahl.