Leitfaden zur KI-Agent-Sandbox
So führen Sie einen KI-Agenten auf Ihrem Mac aus, ohne ihm Ihren Mac zu geben
Die kurze Antwort: Geben Sie dem Agenten eine virtuelle Maschine, nicht Ihr Benutzerkonto. Legen Sie vor dem Start einen Snapshot an, klonen Sie für alles, dem Sie nicht trauen, eine Wegwerf-Kopie, und trennen Sie das Netzwerk, wenn die Aufgabe keines braucht. Dieser Leitfaden vergleicht die Isolationsoptionen auf Apple Silicon und führt durch den Workflow mit dem integrierten MCP-Server von Kyvenza.
Was jede Art von Isolation tatsächlich schützt
Ihr eigenes Benutzerkonto: keine Isolation
Ein Agent, der Shell-Befehle als Sie ausführt, hat alles, was Sie haben: den Schlüsselbund, SSH-Schlüssel, Browser-Sitzungen, Cloud-Zugangsdaten und jede Datei, die Sie lesen können. Ein fehlerhafter Befehl oder eine Prompt-Injection hat dieselbe Reichweite wie Sie.
Ein zweiter macOS-Benutzer: Dateien getrennt, Betriebssystem geteilt
Ein separates Konto hält Ihren Home-Ordner und Ihren Schlüsselbund außer Reichweite, aber es ist dasselbe Betriebssystem mit demselben Kernel. Das hilft bei Versehen, weniger gegen einen Agenten, dem Administratorrechte gegeben werden.
Ein Container: gut für Linux-Werkzeuge, mit Einschränkungen
Container laufen auf dem Mac in einer virtuellen Linux-Maschine und teilen sich deren Kernel. Sie eignen sich für Linux-Werkzeuge ohne Oberfläche, aber ein eingebundener Host-Ordner oder der Docker-Socket gibt dem Agenten einen Weg zurück nach draußen, und macOS- oder Windows-Apps können sie nicht ausführen.
Eine virtuelle Maschine: eine Grenze, die der Hypervisor durchsetzt
Der Gast ist ein eigenes Betriebssystem. Er sieht Ihre Host-Dateien nur, wenn Sie sie freigeben, und mit einem Snapshot lässt sich die ganze Maschine nach einer fehlerhaften Aktion zurückrollen. Das ist der Sweet Spot für Coding-Agenten auf einem Mac.
Eine dedizierte Maschine: am stärksten, aber ein zweites Gerät
Ein Ersatz-Mac-mini bietet physische Trennung. Er kostet aber Geld, muss eingerichtet werden und ist ein weiteres Gerät, das Sie pflegen müssen. Eine VM bietet den Großteil der Isolation auf dem Mac, den Sie ohnehin besitzen.
Eine Kyvenza-VM vs. ein Docker-Container für Agent-Aufgaben
Container sind für viele Agent-Aufgaben in Ordnung und schnell erstellt. Die entscheidenden Unterschiede zeigen sich, wenn der Agent einen vollständigen Desktop, einen macOS- oder Windows-Gast oder eine stärkere Grenze braucht.
| Funktion | Kyvenza | Docker container |
|---|---|---|
| Gast-Betriebssystem | Linux ARM, macOS ARM oder Windows 11 ARM | Nur Linux |
| Isolationsgrenze | Ein eigenes Betriebssystem, vom Hypervisor durchgesetzt | Ein gemeinsamer Linux-Kernel in einer Docker-VM |
| Zurückrollen nach einer fehlerhaften Aktion | Einen Snapshot wiederherstellen; über MCP wird automatisch einer angelegt, bevor ein Agent eine VM startet | Den Container neu aufbauen und alle Volumes wiederherstellen |
| Wegwerf-Kopie | clone_vm: Copy-on-Write, erscheint in etwa einer Sekunde | Ja, neue Container starten schnell |
| Überhaupt kein Netzwerk | Isoliertes Netzwerk; auf Linux führt der Gast-Agent weiterhin Befehle aus und erstellt Screenshots | Ja, mit einer Einstellung ohne Netzwerk |
| Den Bildschirm sehen | screenshot-Tool bei einem Gast mit vollständigem Desktop | Nur Terminal, außer Sie fügen einen Desktop hinzu |
| Beste Eignung | Agenten, die einen echten Desktop oder macOS brauchen, und nicht vertrauenswürdige Installer | Linux-Werkzeuge ohne Oberfläche und CI |
Was Kyvenza heute unterstützt
Eine kurze, ehrliche Liste — damit Sie wissen, was Sie erwartet, und böse Überraschungen ausbleiben.
Heute unterstützt
- Apple Silicon Mac-Serie (M1, M2, M3, M4, M5)
- Windows 11 auf ARM (mit offiziellem Microsoft-Image und -Lizenz)
- Ubuntu ARM (LTS-Versionen)
- Debian ARM
- Fedora ARM
- macOS 14 Sonoma oder neuer (als Host)
- Apple Virtualisierungs-Framework (native Engine)
Noch nicht unterstützt
- GPU- bzw. 3D-Beschleunigung im Windows-Gast
- Mikrofoneingang und USB-Passthrough für Windows-Gäste
- x86- bzw. Intel-Gastbetriebssysteme
- Verschachtelte Virtualisierung
- GPU-Passthrough
Wir listen auf, was wir heute nicht liefern können, damit Sie entsprechend planen können.
So funktioniert es
Eine saubere Basis-VM vorbereiten
Erstellen Sie in Kyvenza einen Linux- oder macOS-Gast, installieren Sie die Werkzeuge, die der Agent braucht, und fahren Sie ihn herunter. Das ist Ihre bewährte Basis. Legen Sie keine persönlichen Zugangsdaten darin ab.
MCP-Server einschalten und den Agenten verbinden
Schalten Sie den Server unter Einstellungen, dann Automation ein und kopieren Sie den Endpunkt, der bereits das Token Ihres Macs enthält. In Claude Code genügt ein Befehl: claude mcp add --transport http kyvenza http://127.0.0.1:59800/mcp/YOUR-TOKEN. Jeder MCP-Client, der eine URL akzeptiert, funktioniert.
Klonen, ausführen, Ergebnis lesen, löschen
Bei aktivierten destruktiven Tools klont der Agent die Basis in eine Sandbox, führt darin den Installer oder das Skript aus, liest die Ausgabe und löscht den Klon. Der Klon ist Copy-on-Write, und gelöschte Daten landen im Papierkorb. Für Code, der nicht nach Hause telefonieren darf, stellen Sie die VM zuerst auf isoliertes Netzwerk.
Häufig gestellte Fragen
Nicht auf Ihrem Hauptkonto. Ein Agent, der Shell-Befehle als Sie ausführen kann, kann Ihren Schlüsselbund, SSH-Schlüssel und Browser-Sitzungen lesen, sodass ein fehlerhafter Befehl oder eine Prompt-Injection dieselbe Reichweite hat wie Sie. Führen Sie ihn in einer virtuellen Maschine aus, die keine Ihrer Zugangsdaten enthält, und legen Sie vor dem Start einen Snapshot an.
Geben Sie dem Agenten eine eigene Maschine
Laden Sie Kyvenza herunter, schalten Sie den MCP-Server ein und lassen Sie Ihren Agenten in einer VM arbeiten, die Sie per Snapshot sichern und wegwerfen können. Einmalig $49 nach der 7-tägigen Testphase.
Weitere Vergleiche