2026 DeepSeek Harness: Mac gemeinsam oder getrennte Konten?

Eine Sitzung läuft weiter, obwohl der nächste Entwickler bereits angemeldet ist. Niemand kann sicher sagen, wer den Prozess gestartet hat.

Die schnellste Lösung lautet: Für eine persönliche, kurzfristige Zusammenarbeit mit einem niedrig eingestuften Repository kann ein dediziertes gemeinsames Konto ausreichen. Bei dauerhafter Mehrpersonennutzung, unterschiedlichen API Keys oder notwendiger Nachvollziehbarkeit sollte jede Person ein eigenes macOS Benutzerkonto erhalten. Unterschiedliche Kunden- oder Vertrauensbereiche benötigen trotzdem getrennte Mac-Umgebungen.

[ SECTION_01 ] Geeignet für Verantwortliche und Betreiber

Dieser Beitrag richtet sich an Teamverantwortliche, die einen Cloud-Mac für mehrere Entwickler bereitstellen möchten und dafür eine belastbare Kontenstruktur brauchen.

Ebenso relevant ist der Leitfaden für den Betrieb von DeepSeek Harness mit dauerhaften Prozessen. Sicherheitsverantwortliche erhalten Kriterien für Repositories, Signaturmaterialien, API Keys, Sitzungsprotokolle und die Rücknahme einzelner Zugriffe.

Die zentrale Frage lautet nicht: „Wer war im Webinterface angemeldet?“ Entscheidend ist: Welcher macOS Benutzerkontext hat den Prozess, die Datei und das Geheimnis tatsächlich verwendet?

[ SECTION_02 ] Die eigentliche Fehlerkette bei einem gemeinsamen Konto

Ein gemeinsames Konto wirkt zunächst einfach. Ein Team meldet sich per Fernzugriff an, öffnet DeepSeek Harness und arbeitet im vorhandenen Projektordner. Der Fehler zeigt sich meist erst beim Übergang zwischen zwei Personen:

1. Entwickler A startet eine Sitzung.
2. DeepSeek Harness erhält Zugriff auf den Arbeitsbereich und auf die konfigurierte Modellberechtigung.
3. Ein Hintergrundprozess bleibt nach dem Browserwechsel oder der Fernzugriffsübergabe aktiv.
4. Entwickler B übernimmt denselben Benutzerkontext.
5. Ein Fehler, eine Dateiänderung oder ein API-Verbrauch wird nachträglich keiner Person sicher zugeordnet.

Eine Webanmeldung löst dieses Problem nicht. Der Browser kann einen Namen oder eine E-Mail-Adresse protokollieren, während das lokale Programm weiterhin unter demselben macOS Benutzer läuft. Für die technische Zuordnung sind daher mindestens fünf Objekte zu verbinden:

• Person oder Dienstverantwortung
• macOS Benutzerkonto
• DeepSeek-Harness-Prozess
• Arbeitsbereich oder Repository
• verwendeter Schlüssel

DeepSeek Harness ist laut den verfügbaren technischen Beschreibungen auf Arbeitsbereiche, Sitzungszustand, Werkzeuge und Modellzugang ausgelegt. Je nach Implementierung können diese Daten lokal in Konfigurationen, Sitzungsdateien, Datenbanken oder Umgebungsvariablen landen. Die konkrete Ablage und der Zugriff müssen deshalb für die eingesetzte Version geprüft werden; eine allgemeine Sicherheitszusage für ein gemeinsames macOS Konto liegt nicht vor. Die technische Referenz zu Arbeitsbereich, Sitzungen und Werkzeugen beschreibt diese lokalen Zustandsbereiche.

Achtung: Das Schließen eines Fensters, das Wechseln des Browsers oder das Beenden einer SSH-Sitzung beendet nicht automatisch alle Kindprozesse. Die Übergabe ist erst abgeschlossen, wenn die Prozessliste und der Arbeitsbereich geprüft wurden.

Ein zeitlich begrenztes gemeinsames Konto ist nur dann vertretbar, wenn der Übergabestandard schriftlich feststeht. Dazu gehören der aktuelle Arbeitsbereich, offene Änderungen, gestartete Prozesse, der verwendete Schlüsseltyp, der nächste Verantwortliche und ein definierter Stop- oder Übernahmeweg.

[ SECTION_03 ] Keychain und Umgebungsvariablen als getrennte Risikozonen

Die macOS Keychain ist kein neutraler Teamtresor. Der Datenzugriff hängt vom Benutzerkontext und von den Zugriffsrechten der Anwendung ab. Die technische Dokumentation beschreibt, dass jeder Benutzer genau eine eigene Data-Protection-Keychain besitzt und das System anhand des aufrufenden Benutzerkontexts die passende Keychain auswählt. Ein Programm im Benutzerkontext und ein Hintergrunddienst ohne Benutzeranmeldung können deshalb unterschiedliche Zugriffspfade haben. Die technische Erklärung zu Benutzerkontexten und Keychains belegt diese Grenze.

Das führt bei einem gemeinsamen Konto zu einer falschen Annahme: Wenn zwei Personen denselben Mac-Account verwenden, sehen sie zwar nicht zwangsläufig jedes geschützte Geheimnis direkt. Sie teilen aber denselben lokalen Vertrauensbereich, dieselben Shell-Initialisierungen, dieselben Konfigurationspfade und häufig dieselbe freigeschaltete Sitzung. Dadurch wird der Weg zu einem bereits autorisierten Schlüssel kürzer.

Umgebungsvariablen verschärfen das Problem. Ein DEEPSEEK_API_KEY, das in einer Shell, einem Startskript, einer Projektdatei oder einem Prozess gesetzt ist, kann für nachfolgende Prozesse sichtbar bleiben. Die Person, die den Schlüssel ursprünglich gesetzt hat, muss nicht mit der Person übereinstimmen, die ihn später nutzt.

Für die Entscheidung sollten drei Schlüsselarten getrennt bewertet werden:

Schlüsseltyp	Geeignete Zuordnung	Gemeinsames Konto	Auslöser für Trennung
Persönlicher API Key	Eine konkrete Person	Nur kurzfristig	Einzelentzug, personenbezogene Abrechnung oder persönliche Haftung
Teamdienstschlüssel	Dienstkonto mit dokumentierter Verantwortung	Möglich, aber nicht im Entwicklerkonto	Unbeaufsichtigter Prozess, Rotation oder Notfallabschaltung
Signaturzertifikat oder privates Signaturmaterial	Stark geschützter Benutzer- oder Build-Kontext	In der Regel ablehnen	Kundencode, Veröffentlichung oder rechtlich relevante Signatur

Die entscheidende Prüffrage lautet: Sind Besitzer, Leser und Widerrufer des Schlüssels drei klar benannte Rollen oder dieselbe unbestimmte Gruppe? Wenn diese Rollen nicht dokumentiert sind, sollte die gemeinsame Nutzung abgelehnt werden.

Die Keychain kann den Zugriff auf einzelne Einträge zusätzlich über Anwendung, Gerätezustand und Authentifizierung begrenzen. Sie ersetzt jedoch keine saubere Teamidentität. Die Übersicht zu Keychain-Zugriffsbedingungen beschreibt die möglichen Zugriffsbeschränkungen.

[ SECTION_04 ] Arbeitsbereich, Sitzungen und Protokolle

Ein Ordnername wie projekt-a ist keine Zugriffskontrolle. Auch eine mündliche Regel wie „Bitte nur den eigenen Unterordner verwenden“ schützt nicht vor einem Agenten, Plugin, Shell-Befehl oder versehentlichen Dateizugriff.

Unter einem gemeinsamen Home-Verzeichnis können mehrere Grenzen überlappen:

• Repository-Dateien und lokale Klone
• Agent-Konfigurationen
• Plugins oder Tooldefinitionen
• Sitzungsprotokolle
• temporäre Dateien
• Shell-Historie
• lokale Datenbanken
• Zugangsdaten in Konfigurationsdateien

DeepSeek Harness kann je nach Version Sitzungen fortsetzen oder lokale Zustände wiederverwenden. Deshalb muss geprüft werden, ob eine neue Person eine alte Sitzung auflisten, fortsetzen oder deren Kontext indirekt lesen kann. Die Existenz eines getrennten Weblogin-Protokolls beantwortet diese Frage nicht.

Bei einem einzigen, nicht sensiblen Repository kann ein gemeinsamer Arbeitsbereich vorübergehend funktionieren. Voraussetzung sind ein leerer Übergabestatus, ein definierter Branch, eine Prüfung offener Änderungen und ein Protokoll der verantwortlichen Person.

Sobald jedoch unterschiedliche Kundenprojekte, vertrauliche Daten oder verschiedene Schutzklassen beteiligt sind, reicht die Ordnerstruktur nicht mehr aus. Dann ist ein eigenes macOS Benutzerkonto die Mindestmaßnahme. Bei unterschiedlichen Kunden oder rechtlich getrennten Vertrauensbereichen sollte zusätzlich eine eigene Mac-Umgebung eingesetzt werden. Konten auf demselben System sind keine vollständige Mandantentrennung.

macOS besitzt für Dateien in geschützten Verzeichnissen zusätzliche Datenschutzabfragen und Berechtigungsmechanismen. Diese Regeln können den Zugriff einzelner Anwendungen beeinflussen, ersetzen aber keine Projekt- und Identitätsarchitektur. Die Dokumentation zur App-Dateikontrolle erläutert diese zusätzliche Systemgrenze.

[ SECTION_05 ] Hintergrundprozesse und Übergaben

Die gefährlichste Übergabesituation ist nicht die aktive Sitzung, sondern der Prozess, der niemand mehr beobachtet. Ein Harness-Prozess, ein lokaler Server, ein MCP-Dienst, ein Queue-Worker oder ein automatisierter Auftrag kann nach dem Personenwechsel weiterlaufen.

Dabei bleiben möglicherweise erhalten:

• der ursprüngliche Arbeitsbereich
• die ursprünglichen Umgebungsvariablen
• die ursprünglichen Dateiberechtigungen
• die ursprüngliche Netzwerkverbindung
• die ursprüngliche Sitzung
• die ursprüngliche Kosten- oder Verbrauchszuordnung

Der Betreiber sollte für jeden dauerhaften Prozess vier Angaben erfassen:

1. Besitzer: persönliches Konto oder Dienstkonto?
2. Startweg: Terminal, Login-Start, Launch-Agent, CI/CD oder anderer Scheduler?
3. Stoppeinstieg: Welcher kontrollierte Befehl beendet den Prozess?
4. Übernahmestandard: Welche Person darf ihn übernehmen und mit welcher Prüfung?

Ein persönliches Konto ist für interaktive Entwicklung geeignet. Ein Dienstkonto ist besser, wenn ein Prozess unabhängig von einer einzelnen Person weiterlaufen soll. Das Dienstkonto darf nicht als bequemes Sammelkonto für Entwickler verwendet werden. Es braucht einen eigenen Schlüssel, eine dokumentierte verantwortliche Stelle und eine begrenzte Dateiberechtigung.

Besonders wichtig ist die Unterscheidung zwischen einem Benutzerprozess und einem Systemdienst. Die technische Keychain-Dokumentation weist darauf hin, dass bestimmte geschützte Keychain-Funktionen nur im Benutzerkontext verfügbar sind, während ein launchd-Daemon außerhalb dieses Kontexts andere Keychain-Bedingungen vorfindet. Ein Dienst, der im falschen Kontext gestartet wird, kann daher entweder unerwartet scheitern oder auf einen anderen Speicherpfad ausweichen. Die Referenz zu Keychains in Benutzer- und Systemkontexten sollte vor der Automatisierung geprüft werden.

[ SECTION_06 ] Auditierbarkeit und Rücknahme

Ein gemeinsames Konto schwächt die Beweiskette. Zeitstempel und Sitzungsnamen können vorhanden sein, aber sie beweisen nicht zuverlässig, welche Person einen Befehl bestätigt, ein Repository verändert oder einen Schlüssel verwendet hat.

Die wichtigsten Auditfragen sind:

• Ist der Start einer Sitzung einer Person oder einem Dienst zugeordnet?
• Wird der verwendete Arbeitsbereich protokolliert?
• Ist ersichtlich, welcher Prozess Änderungen ausgeführt hat?
• Lassen sich persönliche und dienstliche Schlüssel unterscheiden?
• Kann ein einzelner Zugriff widerrufen werden, ohne andere Aufgaben zu stoppen?
• Gibt es vor der Übergabe eine Prüfung auf offene Änderungen?

Die letzte Frage ist auch für das Ausscheiden eines Teammitglieds entscheidend. Eine brauchbare Rücknahme muss gezielt erfolgen. Nur die Person wird entfernt, deren persönliche Zugänge widerrufen werden sollen. Ein unabhängiger Dienstprozess bleibt verfügbar. Dafür müssen persönliche Sitzungen, Shell-Zugänge, API Keys, Konfigurationsdateien und laufende Prozesse getrennt von der Dienstumgebung behandelt werden.

Die Einrichtung eines eigenen Kontos verbessert diese Zuordnung, schafft aber keine vollständige Sicherheitsisolierung. Gemeinsame Gruppenordner, Administratorrechte, falsch gesetzte Dateiberechtigungen, weitergereichte Schlüssel oder ein gemeinsam genutzter Dienstprozess können die Grenze wieder öffnen. macOS empfiehlt bei mehreren Personen eigene Konten, damit Einstellungen und Zugriffe nicht gegenseitig vermischt werden. Die Anleitung zur Verwaltung mehrerer Benutzerkonten beschreibt diesen Grundsatz.

[ SECTION_07 ] Vier Kontenmodelle mit klaren Ablehnungsbedingungen

Die folgende Entscheidungshilfe ordnet nicht nach Teamgröße, sondern nach Risiko und Betriebsform:

• Wenn nur eine Person nach der anderen an einem niedrig eingestuften Repository arbeitet, keine persönlichen Schlüssel verwendet werden und jede Übergabe dokumentiert wird, dann kann ein dediziertes gemeinsames Konto als temporäre Lösung akzeptiert werden. Sonst zurück zu persönlichen Konten.
• Wenn mehrere Entwickler dauerhaft interaktiv arbeiten, persönliche API Keys nutzen oder einzelne Änderungen nachvollziehbar sein müssen, dann erhält jede Person ein eigenes macOS Benutzerkonto. Sonst bleibt die Zuordnung unzureichend.
• Wenn DeepSeek Harness unbeaufsichtigt, automatisch oder nach Neustarts weiterläuft, dann wird ein separates Dienstkonto mit eigenem Schlüssel und festem Stoppeinstieg verwendet. Sonst darf kein persönlicher Account als Prozessbesitzer dienen.
• Wenn zwei Kunden, Datenschutzklassen oder Vertrauensbereiche betroffen sind, dann wird eine unabhängige Mac-Umgebung eingeplant. Sonst kann ein Konto allein fälschlich als Mandantentrennung betrachtet werden.
• Wenn ein einzelner Benutzer entzogen werden muss, ohne laufende Teamdienste zu beeinflussen, dann ist die Struktur abnahmefähig. Sonst muss sie vor dem produktiven Einsatz umgebaut werden.

Für die operative Bewertung kann jede Ebene mit einer einfachen Punktzahl von 0 bis 2 bewertet werden:

• 0 Punkte: nicht nachweisbar
• 1 Punkt: dokumentiert, aber nicht getestet
• 2 Punkte: dokumentiert und in einer Übergabe- oder Widerrufsübung bestätigt

Bewertet werden Identität, Arbeitsbereich, Schlüssel, Prozessbesitz und Rücknahme. Ein gemeinsames Konto sollte nur für einen niedrigen Schutzbedarf akzeptiert werden. Bei persönlichem Signaturmaterial, Kundengeheimnissen oder fehlender Einzelrücknahme ist die Entscheidung unabhängig vom Punktestand abzulehnen.

[ SECTION_08 ] Umsetzung ohne Kontenchaos

Die Einführung sollte nicht mit dem Anlegen vieler Konten beginnen. Zuerst muss der Ist-Zustand sichtbar werden.

1. Objekte erfassen: Für jede Nutzung werden Person, macOS Benutzer, Harness-Sitzung, Repository, Prozess und Schlüssel in einer Zuordnungsliste erfasst.
2. Schutzklassen vergeben: Repositories werden mindestens nach intern, vertraulich und kundenbezogen bewertet. Persönliche Schlüssel und Signaturmaterialien erhalten eine eigene Sperrregel.
3. Prozessinventar erstellen: Der Betreiber prüft aktive Prozesse, Startmechanismen, offene Terminals und wiederanlaufende Dienste. Browser- oder VNC-Sitzungen gelten nicht als Nachweis für einen sauberen Prozesswechsel.
4. Kontenmodell wählen: Temporäre gemeinsame Nutzung, persönliche Konten, Dienstkonto oder getrennte Umgebung werden anhand der oben genannten Bedingungen entschieden.
5. Arbeitsbereiche neu zuordnen: Jede Umgebung erhält einen klaren Pfad, eine verantwortliche Person oder einen Dienstbesitzer und eine Regel für offene Änderungen. Ordnernamen dienen nur der Orientierung.
6. Schlüssel neu ausstellen: Persönliche Schlüssel werden nicht in ein Teamkonto kopiert. Dienstschlüssel werden ausschließlich im Dienstkontext hinterlegt. Code-Signaturmaterial wird aus der Entwicklerübergabe herausgenommen, wenn eine getrennte Build-Umgebung erforderlich ist.
7. Übergabe testen: Eine Person beendet ihre Sitzung, dokumentiert offene Aufgaben und übergibt den Prozess nach festgelegtem Verfahren. Die nächste Person prüft Arbeitsbereich, Sitzung und Prozessbesitzer.
8. Widerruf testen: Ein Testkonto oder eine Testberechtigung wird entfernt. Danach wird geprüft, ob der betreffende Zugriff tatsächlich scheitert und ob unabhängige Dienstaufgaben weiterlaufen.
9. Nachweis speichern: Die Abnahme enthält Datum, Verantwortliche, geprüfte Objekte, Ergebnis und Rückfallweg. Ohne diesen Nachweis ist „getrennt“ nur eine Absichtserklärung.

Erfahrung aus dem Betrieb: Die häufigste Lücke liegt nicht beim eigentlichen API Key, sondern bei alten Shell-Dateien, wiederaufgenommenen Sitzungen und Prozessen, die unter dem vorherigen Benutzer weiterarbeiten.

Für Teams, die zunächst einen einzelnen Mac bereitstellen, kann der Mac-Mietbetrieb von NOVAKVM als Ausgangspunkt für eine getrennte Betriebsplanung dienen. Die Konten- und Prozessabnahme bleibt jedoch eine Aufgabe des jeweiligen Teams.

[ SECTION_09 ] FAQ für die Kontenentscheidung

Die vier häufigsten Fehlannahmen lassen sich so zusammenfassen: Ein gemeinsamer Login ist keine persönliche Ausführung, ein Ordnername ist keine Berechtigung, ein API Key ist kein vollständiges Identitätsmodell und ein geschlossenes Fenster ist kein Prozessstopp.

Wenn der geplante Einsatz nur ein niedrig sensibles Repository und eine kurze Übergangsphase betrifft, kann das gemeinsame Konto mit dokumentierter Übergabe vertretbar sein. Für langfristige Teamarbeit sollte die Struktur dagegen auf persönliche Konten plus klar getrennte Dienstprozesse umgestellt werden.

[ SECTION_10 ] Der bessere nächste Schritt für einen gemieteten Mac

Ein vorhandener gemeinsamer Mac ist kurzfristig bequem, hat aber drei konkrete Schwächen: Die Verantwortung für laufende Harness-Prozesse bleibt unklar, persönliche und dienstliche Schlüssel können in denselben lokalen Kontext geraten, und der Entzug einer einzelnen Person lässt sich schwer beweisen. Ein eigener lokaler Mac löst diese Punkte nur dann, wenn Konten, Arbeitsbereiche und Prozesse ebenso sauber geplant werden.

Für zeitlich begrenzte Entwicklungsphasen, Abnahmetests oder einen kontrollierten Cloud-Mac-Betrieb kann ein von NOVAKVM bereitgestellter Mac deshalb sinnvoller sein als ein ungeklärtes Sammelkonto auf vorhandener Hardware. Vor der Übergabe sollte das Team die Tabelle „Person – macOS Konto – Harness-Prozess – Repository – Schlüssel“ ausfüllen und anschließend eine minimale Aufgabenübernahme sowie einen Einzelwiderruf durchführen. Wenn beides nicht gelingt, ist nicht das Passwort das Problem, sondern die Umgebung muss getrennt werden.

Häufige Fragen

Können mehrere Personen DeepSeek Harness unter einem Konto verwenden?

Ja, aber nur als zeitlich begrenzte Übergangslösung. Dafür müssen Arbeitsbereich, verwendeter Schlüssel, gestartete Prozesse, Übergabezeitpunkt und verantwortliche Person dokumentiert werden. Das Modell passt nur zu niedrig eingestuften Repositories ohne personenbezogene Daten, Kundengeheimnisse oder persönliche Signaturmaterialien. Bei dauerhafter Teamnutzung ist ein eigenes macOS-Benutzerkonto pro Person die belastbarere Wahl.

Wie lassen sich API Keys auf einem entfernten Mac trennen?

Die Trennung beginnt mit unterschiedlichen macOS Benutzerkonten und endet nicht bei verschiedenen Umgebungsvariablen. Persönliche Schlüssel gehören in den persönlichen Benutzerkontext, Teamdienstschlüssel in ein ausdrücklich verwaltetes Dienstkonto. Zusätzlich müssen Sitzungen, Shell-Initialisierung, Konfigurationsdateien, Arbeitsverzeichnisse und laufende Prozesse geprüft werden. Ein gemeinsamer Home-Ordner oder ein weitergereichter Schlüssel hebt die Trennung wieder auf.

Wann ist ein Dienstkonto besser als ein persönliches Konto?

Ein Dienstkonto ist sinnvoll, wenn DeepSeek Harness dauerhaft, unbeaufsichtigt oder als wiederanlaufender Prozess arbeitet. Es gehört dann nicht einer einzelnen Person, sondern einem dokumentierten Dienst mit eigenem Schlüssel, Startweg, Protokollierung und Notfallkontakt. Für interaktive Entwicklungsarbeit bleibt ein persönliches Konto geeigneter, weil Änderungen, Sitzungen und Freigaben einer konkreten Person zugeordnet werden können.

Wie wird eine Agent-Umgebung nach dem Ausscheiden eines Teammitglieds zurückgenommen?

Zuerst werden persönliche Schlüssel und Sitzungen gesperrt, danach laufende Prozesse beendet und Arbeitsbereiche auf offene Änderungen geprüft. Anschließend werden Zugriffsrechte, gespeicherte Konfigurationen und Fernzugänge kontrolliert. Die Rücknahme gilt erst als abgeschlossen, wenn eine Testperson keinen Zugriff mehr erhält, während ein unabhängiger Dienst weiterläuft. Genau diese Einzelentzug-Prüfung sollte vorab geübt werden.