DeepSeek Harness Seatbelt-Sandbox für Mac 2026

Ein Agent liest Dateien außerhalb des Projekts, startet ein Skript mit unerwarteten Nebenwirkungen oder übernimmt ein Credential aus der Shell-Umgebung – und der Begriff „Sandbox“ klingt trotzdem beruhigend.

Gewinner: Die DeepSeek Harness Seatbelt-Sandbox ist für erste Tests die sinnvollere Schutzschicht, sofern sie tatsächlich aktiv ist und in einem risikoarmen Repository geprüft wird. Sie ist keine vollständige Agent-Isolierung und darf Arbeitsbereich, Netzwerk, Credentials oder Befehlsfreigaben nicht ersetzen.

Dieser Beitrag richtet sich an:

• Entwickler, die DeepSeek Harness auf einem Mac Shell-Befehle ausführen lassen möchten.
• Sicherheitsingenieure, die die Betriebssystemgrenzen eines Agents bewerten.
• Technische Verantwortliche, die den Umfang eines Tests auf einem entfernten Mac festlegen.

Letzte Aktualisierung: 18.08.2026. Die Einordnung wurde anhand des aktuellen offiziellen DeepSeek-Harness-Repositories, der dort beschriebenen Sandbox- und Plugin-Architektur sowie der offiziellen macOS-Sicherheitsdokumentation geprüft. DeepSeek Harness befindet sich weiterhin in der Developer Preview; Änderungen an Kompatibilität und Implementierung sind daher möglich. (github.com)

Seatbelt-Unterstützung und vollständige Isolation

Der wichtigste Unterschied betrifft die Kontrollebene. Eine Seatbelt-Sandbox begrenzt Fähigkeiten eines Prozesses. Der ausgewählte Harness-Arbeitsbereich bestimmt dagegen, welche Dateien und Projektressourcen der Agent überhaupt als Arbeitskontext erhält. Beides kann zusammenwirken, ist aber nicht dasselbe.

Die offizielle Architektur beschreibt Sandbox als austauschbares Backend, das gestartete Prozesse vor der Ausführung umschließt. Gleichzeitig sind Dateisystem, Shell, Tools, Credentials, Telemetrie und Freigabepolitik eigenständige Komponenten der Plugin-Struktur. Ein Arbeitsbereichsname oder ein Paketverzeichnis beweist deshalb nicht, dass jede Aktion bereits durch Seatbelt abgesichert ist. (github.com)

Für die Bewertung am 18.08.2026 gelten drei vorsichtige Aussagen:

1. Seatbelt ist als macOS-Backend vorgesehen beziehungsweise im offiziellen Architekturmodell berücksichtigt.
2. Aus einem Verzeichnisnamen, einem Paketnamen oder einer Beispielkonfiguration lässt sich keine automatische Aktivierung ableiten.
3. Die tatsächlich wirksame Policy muss in der verwendeten Version und im konkreten Startmodus geprüft werden.

Das ist für macOS besonders relevant, weil Apple Sandbox-Zugriffe auf Dateien, Netzwerkverbindungen und weitere Ressourcen nicht pauschal freigibt, sondern über explizite Berechtigungen und Laufzeitregeln begrenzt. Die Sandbox reduziert damit den möglichen Schaden eines kompromittierten Prozesses, verhindert aber nicht automatisch fehlerhafte oder riskante Geschäftslogik. (developer.apple.com)

Zwei Kontrollebenen im Vergleich

Wer nur den Workspace prüft, kann eine aktive Seatbelt-Policy übersehen. Wer nur Seatbelt prüft, kann Credentials, Plugins oder einen falsch gewählten Arbeitsbereich übersehen.

macOS-Dateigrenzen und Arbeitsbereich

Automatische Aktivierung der Seatbelt-Sandbox

DeepSeek Harness sollte auf macOS nicht als „automatisch sicher“ behandelt werden. Die offizielle Dokumentation weist auf eine Plugin-basierte Architektur und eine konfigurierbare Sandbox- beziehungsweise Approval-Schicht hin. Daraus folgt eine Prüfpflicht, nicht die Annahme eines sicheren Standardwerts. (github.com)

Die erste Kontrolle sollte deshalb den tatsächlich gestarteten Prozess und die geladene Konfiguration erfassen:

dsh --profile web --dump-config
ps aux | grep -i '[d]sh'

Die Ausgabe muss nicht nur den Profilnamen zeigen. Entscheidend sind:

• verwendeter Startmodus;
• aktive Sandbox-Komponente;
• Arbeitsbereichspfad;
• Freigabepolitik;
• geladene Plugin- und MCP-Konfiguration;
• mögliche Umgebungsvariablen mit Policy-Einfluss.

Ein plausibler Testfall arbeitet mit drei Pfaden:

~/dsh-test/allowed/
~/dsh-test/denied/
~/dsh-test/output/

Im erlaubten Pfad liegt eine harmlose Testdatei. Der abgelehnte Pfad enthält keine produktiven Daten, sondern nur einen Marker. Der Agent soll die Datei im Arbeitsbereich lesen, die Datei außerhalb des Arbeitsbereichs lesen und eine Datei im Ausgabeordner erzeugen.

Datei- und Artefaktnachweis

Die Auswertung muss zwischen „Agent hat die Datei nicht angefordert“, „Tool hat den Zugriff abgelehnt“ und „Mensch hat den Zugriff genehmigt“ unterscheiden. Nur die zweite Kategorie belegt eine wirksame technische Grenze.

Seatbelt kann den Prozesszugriff auf konkrete Ressourcen begrenzen. Die macOS-Plattform selbst schützt zusätzlich bestimmte Systembereiche. System Integrity Protection gilt für Prozesse unabhängig davon, ob sie sandboxed sind oder administrative Rechte besitzen. Das bedeutet jedoch nicht, dass private Projektordner, SSH-Dateien oder lokale Konfigurationsdateien automatisch geschützt sind. (support.apple.com)

Shell, Unterprozesse und Toolchains

Ein Agent führt selten nur einen einzelnen Befehl aus. Ein Build startet Compiler, Linker, Test Runner, Package Manager und manchmal weitere Hilfsprozesse. Ein Skript kann wiederum Shells, Interpreter, Git-Hooks oder externe Tools aufrufen. Dadurch wächst die effektive Operationsfläche deutlich.

Die offizielle DeepSeek-Harness-Architektur beschreibt eine getrennte Tool-Ausführungspipeline und einen Sandbox-Backend-Punkt für gestartete Prozesse. Der entscheidende Prüfpunkt lautet daher: Wird nur der direkte Shell-Prozess eingeschränkt, oder erbt auch der vollständige Kindprozessbaum die Policy? (github.com)

Ein ungefährlicher Test kann die Prozessstruktur sichtbar machen:

sh -c 'printf "parent=%s\n" "$$"; sh -c "printf \"child=%s\n\" \"$$\"; pwd; id"'

Danach sollte ein Skript geprüft werden, das absichtlich mehrere Ebenen erzeugt:

cat > ./process-tree-test.sh <<'EOF'
#!/bin/sh
printf 'level-1=%s\n' "$$"
sh -c 'printf "level-2=%s\n" "$$"; python3 -c "import os; print(\"level-3=\" + str(os.getpid()))"'
EOF

chmod +x ./process-tree-test.sh
./process-tree-test.sh

Dabei geht es nicht darum, eine bestimmte Ausgabe zu erzwingen. Es geht um die Dokumentation, ob jeder Unterprozess unter derselben Einschränkung läuft.

Eine Seatbelt-Sandbox beurteilt außerdem nicht automatisch, ob ein Befehl fachlich riskant ist. npm install, git reset, ein Datenbankmigrationstool oder ein Skript zum Löschen temporärer Dateien können technisch erlaubt und betrieblich trotzdem falsch sein. Die Sicherheitsentscheidung muss deshalb mindestens aus drei Schichten bestehen:

1. Policy: Darf der Prozess den Vorgang technisch ausführen?
2. Approval: Ist die konkrete Aktion für diesen Lauf genehmigt?
3. Review: Ist die Änderung fachlich und sicherheitsseitig akzeptabel?

Wer die Befehlsfreigabe deaktiviert, weil Seatbelt aktiv ist, entfernt eine wichtige Kontrollschicht. Gerade bei neuen Plugins und Toolchains bleibt eine „on request“-Freigabe für schreibende, destruktive oder netzwerkfähige Befehle sinnvoll.

Netzwerk, MCP und externe Werkzeuge

Seatbelt und Verbindungen nach außen

Eine Prozesssandbox ist keine automatisch aktivierte Netzwerk-Firewall. macOS unterscheidet zwischen Dateizugriffen, ausgehenden Verbindungen und weiteren Ressourcen. Apple dokumentiert Netzwerkberechtigungen separat. Daraus folgt: Seatbelt darf nicht als pauschale Blockade aller externen Verbindungen beschrieben werden. (developer.apple.com)

Bei DeepSeek Harness sind mindestens drei Ebenen getrennt zu prüfen:

• Lokaler Prozess: Darf der gestartete Prozess einen Socket öffnen?
• Netzwerkpolicy: Welche Ziele, Ports oder DNS-Auflösungen sind erlaubt?
• MCP- oder Plugin-Verhalten: Welche Daten sendet ein externes Werkzeug selbstständig?

Ein MCP-Server kann zum Beispiel als lokaler Prozess gestartet werden, aber anschließend eine Verbindung zu einem externen Dienst aufbauen. Selbst wenn der Agent nur einen lokalen Tool-Aufruf sieht, entsteht damit eine zweite Vertrauensbeziehung.

Der erste Netzwerkversuch sollte ohne Quellcode, Tokens, Kundendaten oder interne Hostnamen erfolgen:

curl --connect-timeout 3 https://example.invalid
curl --connect-timeout 3 https://www.apple.com

Der erste Aufruf dient als nicht erreichbares Testziel. Der zweite prüft nur, ob eine ausgehende Verbindung technisch möglich ist. Die Ausgabe muss vollständig protokolliert werden, einschließlich Exit-Code, Fehlermeldung und verwendeter Prozesspolicy. Ein erfolgreicher Zugriff ist kein Beweis für eine unsichere Konfiguration. Er zeigt lediglich, dass diese Verbindung nicht an dieser Stelle blockiert wurde.

Für produktive Tests sollte die Zielmenge danach explizit reduziert werden. Ein Agent benötigt möglicherweise Zugriff auf eine Modell-API, einen Paketserver oder ein Quellcode-Repository. Das rechtfertigt nicht automatisch freien Internetzugang. Die Netzwerkprüfung gehört in eine vollständige Sicherheitsabnahme, wenn Datei-, Prozess-, Netzwerk- und Credential-Grenzen gemeinsam dokumentiert werden.

Credentials, Umgebungsvariablen und Protokolle

Eine Seatbelt-Sandbox löst kein Credential-Management. Ein API-Schlüssel kann auf mehreren Wegen in Reichweite eines Agents gelangen:

• als Umgebungsvariable des Elternprozesses;
• in einer Konfigurationsdatei im Home-Verzeichnis;
• in einer MCP-Konfiguration;
• in Shell-History oder Build-Skripten;
• in Fehlermeldungen, Session-Logs oder Tool-Ausgaben.

Die offizielle Harness-Architektur führt Credentials und Telemetrie als eigene Komponenten neben Sandbox und Approval auf. Das ist ein wichtiger Hinweis: Diese Bereiche sind nicht automatisch durch dieselbe Prozesspolicy erledigt. (github.com)

Für die erste Prüfung genügt ein künstlicher Marker:

export DSH_TEST_TOKEN='REDACTED-TEST-VALUE'
env | grep DSH_TEST_TOKEN

Der Test muss anschließend klären:

1. Erbt der Agent die Variable?
2. Kann ein Kindprozess sie lesen?
3. Wird sie in der Session-Historie gespeichert?
4. Erscheint sie in einer Fehlermeldung?
5. Wird sie an ein MCP-Tool oder einen externen Dienst weitergereicht?

Echte Schlüssel gehören nicht in diesen Test. Auch ein teilweise maskierter realer Schlüssel ist ungeeignet, wenn der Kontext Rückschlüsse auf Mandant, Umgebung oder Dienst erlaubt. Für produktive Nutzung sollte der Schlüssel möglichst kurzlebig, auf einen Dienst beschränkt und von der Build-Identität getrennt sein. Eine Rotation muss vorbereitet sein, bevor ein Agent Zugriff auf nichtöffentliche Systeme erhält.

Unter DSGVO-Gesichtspunkten ist zusätzlich zu klären, welche Session-Daten lokal gespeichert, an Modellendpunkte übertragen und für spätere Wiederaufnahme vorgehalten werden. Ein sicherer Prozesszugriff verhindert keine unzulässige Übermittlung von Quellcode oder personenbezogenen Daten.

Remote Mac und laufende Agent-Sitzungen

Cloud-Mac als getrennte Umgebung

Ein entfernter Mac kann die Vermischung mit privaten Dateien, Browserprofilen und lokalen SSH-Schlüsseln reduzieren. Er liefert aber keine automatische Sicherheitskonfiguration. Die tatsächliche Verantwortung verteilt sich auf mehrere Komponenten:

• Remote-Zugang und Netzwerkfreigabe;
• Systemkonto und Administratorrechte;
• Arbeitsbereich und Dateiablage;
• DeepSeek-Harness-Profil;
• MCP-Server und Plugins;
• Prozess- und Befehlsfreigaben;
• Session-Logs und Credential-Speicher.

Wer nur einen separaten Rechner mietet, hat damit noch keine geprüfte Agent-Isolierung. Ein gemeinsam genutztes System kann für öffentliche Beispielprojekte ausreichen. Für interne Repositories sollte ein unabhängiger Systembenutzer oder eine vollständig getrennte Umgebung vorgesehen werden. Bei besonders sensiblen Projekten ist ein Testaufschub besser als eine unklare Freigabe.

Die Auswahl kann anhand dieser Bedingungen erfolgen:

Für die technische Beschaffung sind Stabilität, Zugriffskontrolle und nachvollziehbare Übergabe wichtiger als die bloße Verfügbarkeit eines Mac. Bei der Auswahl eines geeigneten Standorts oder einer Übergabeumgebung sollten technische Verantwortliche die verfügbaren Mac-Optionen, Zugriffswege und Rücksetzprozesse getrennt bewerten; regionale Unterschiede bei Bereitstellung und Zugriff sind kein Ersatz für eine Sicherheitsprüfung. Eine Übersicht der verfügbaren Mac-Umgebungen finden Sie bei SFTPMAC. Für die Bewertung eines konkreten Remote-Zugangs kann zusätzlich eine regionale Bereitstellungsseite wie die Mac-Umgebung in Virginia herangezogen werden. Die Entscheidung über die Sicherheitsstufe muss jedoch aus dem Projektinhalt entstehen, nicht aus dem Mietmodell.

Ein entfernter Mac hat gegenüber der lokalen Arbeitsstation drei reale Vorteile: Er kann vom persönlichen Home-Verzeichnis getrennt werden, lässt sich nach einem Test leichter zurücksetzen und kann für einen klar begrenzten Zweck reserviert werden. Nachteile bleiben: Der Remote-Zugang selbst ist ein Angriffsweg, Administratorrechte können die Trennung schwächen, und ein falsch konfiguriertes Plugin kann weiterhin Daten aus dem Testsystem abziehen.

Zusätzlich sollte vor einer längeren Laufzeit die geplante Mac-Umgebung anhand einer getrennten Übergabeliste geprüft werden. Dazu gehören Remote-Zugang, Systemkonto, Arbeitsbereich, installierte Plugins und Rücksetzweg. Diese Prüfung sollte die konkrete Bereitstellungsregion, Zugriffsart und Löschung des Testkontos dokumentieren; die bloße Existenz eines Angebots ersetzt keine technische Abnahme. Bei der Vorbereitung einer späteren Übergabe kann dieselbe Übersicht erneut herangezogen werden, um Berechtigungen und Rücksetzschritte nachvollziehbar zu protokollieren.

Erste Prüfsequenz nach dem Update

Die erste Runde sollte nicht mit einem produktiven Repository beginnen. Eine belastbare Reihenfolge sieht so aus:

1. Version festhalten.
   Notieren Sie macOS-Version, Architektur, DeepSeek-Harness-Version, Startprofil und verwendete Plugin-Versionen. Bei einer Developer Preview ist diese Kombination für jede spätere Reproduktion erforderlich. (github.com)

2. Aktive Konfiguration exportieren.
   Lassen Sie die tatsächlich geladene Profilkonfiguration ausgeben. Prüfen Sie Sandbox, Workspace, Approval, Credentials und MCP getrennt.

3. Test-Workspace anlegen.
   Verwenden Sie ein leeres oder öffentliches Repository mit künstlichen Marker-Dateien. Produktive Schlüssel, SSH-Dateien und Browserprofile bleiben außerhalb der Testumgebung.

4. Dateigrenzen prüfen.
   Testen Sie einen erlaubten Lesezugriff, einen verweigerten Nachbarpfad, einen erlaubten Schreibpfad und einen symbolischen Link. Pro Test werden Pfad, Ergebnis und Fehlermeldung gespeichert.

5. Prozessbaum prüfen.
   Starten Sie ein harmloses Skript mit mindestens einem Unterprozess. Dokumentieren Sie, ob der Kindprozess dieselbe Einschränkung erbt.

6. Netzwerk mit Testzielen prüfen.
   Verwenden Sie ein nicht erreichbares Ziel und ein bewusst erlaubtes Ziel ohne sensible Nutzdaten. Prüfen Sie anschließend MCP-Verbindungen separat.

7. Credential-Fluss prüfen.
   Nutzen Sie ausschließlich einen künstlichen Marker. Suchen Sie danach in Terminalausgabe, Session-Log, Fehlerdatei und Tool-Resultaten.

8. Freigabepolitik bestätigen.
   Lassen Sie schreibende und netzwerkfähige Befehle nicht stillschweigend durchlaufen. Wenn eine Aktion trotz Policy unklar bleibt, wird sie abgelehnt.

9. Rückfall vorbereiten.
   Vor der Ausweitung muss feststehen, wie gefährliche Plugins deaktiviert, laufende Prozesse beendet, Zugangsdaten rotiert und der Workspace verworfen werden.

10. Abnahme dokumentieren.
    Ein Test gilt erst als abgeschlossen, wenn erfolgreiche und verweigerte Fälle, Versionen, Policies und Abweichungen gemeinsam archiviert sind.

Ein praktisches Protokoll kann so aussehen:

System: macOS <Version>
Harness: <Version>
Profil: <Profilname>
Sandbox: <erkannte Policy oder unbekannt>
Workspace: <Pfad>
Approval: <Policy>

Datei außerhalb Workspace: VERWEIGERT / ERLAUBT / UNKLAR
Kindprozess: GLEICHE POLICY / ABWEICHEND / UNKLAR
Testziel Netzwerk: BLOCKIERT / ERREICHBAR / UNKLAR
Credential-Marker im Log: NICHT GEFUNDEN / GEFUNDEN
Rückfallaktion: <konkreter Befehl oder Prozess>

Wenn ein Kernpunkt „unklar“ bleibt, sollte der Agent nicht auf ein Repository mit internen Daten losgelassen werden. Die richtige Reaktion ist eine engere Policy, ein abgeschaltetes Tool oder eine getrennte Umgebung.

Entscheidung für den nächsten Schritt

Für Entwickler mit einem risikoarmen Repository ist die Seatbelt-Unterstützung ein sinnvoller Prüfpunkt. Sie kann die Reichweite gestarteter macOS-Prozesse begrenzen und damit eine technische Barriere zwischen Agent und Systemressourcen schaffen. Sie beweist aber weder korrekte Workspace-Grenzen noch sichere MCP-Kommunikation oder geschützte Credentials.

Für Sicherheitsingenieure ist deshalb die entscheidende Frage nicht „Ist Seatbelt vorhanden?“, sondern „Welche konkrete Aktion wird in welcher Prozesskette mit welcher Policy erlaubt?“ Für technische Verantwortliche lautet die Entscheidung: Erst testen, dann den Workspace erweitern. Bei unklaren Ergebnissen ist ein eigener Remote-Mac mit getrenntem Konto besser als die Ausweitung auf eine persönliche Entwicklungsstation.

Die aktuelle Alternative – DeepSeek Harness direkt auf dem Alltags-Mac, mit gemeinsamem Home-Verzeichnis, vorhandenen SSH-Schlüsseln und dauerhaftem Netzwerkzugang – hat vier klare Nachteile: persönliche und geschäftliche Daten liegen näher beieinander, Fehlkonfigurationen sind schwerer reproduzierbar, Credentials können aus der Umgebung geerbt werden, und ein Rücksetzen nach einem fehlgeschlagenen Test ist aufwendiger. Für zeitlich begrenzte Tests bietet ein separat eingerichteter Mac von SFTPMAC deshalb häufig die sauberere Ausgangslage. Das verbessert nicht automatisch die Sicherheit; es schafft aber eine Umgebung, in der Datei-, Prozess-, Netzwerk- und Credential-Grenzen getrennt abgenommen werden können.

Wer diesen Weg wählt, sollte vor einer längeren Laufzeit oder der Aktivierung zusätzlicher Plugins eine vollständige Sicherheitsabnahme und eine separate Übergabeprüfung des Remote-Mac durchführen. Entscheidend bleibt, dass erfolgreiche und verweigerte Zugriffe dokumentiert sind und für jeden fehlgeschlagenen Test eine konkrete Rückfallaktion bereitsteht.