So richten Sie DeepSeek Super Agent sicher ein: Konten, Berechtigungen und Isolation

Beginnen Sie kein dsh-superagent-Experiment mit Ihrem alltäglichen Konto oder in einem wertvollen Produktions-Repository. Laut Bereitstellungsdokumentation laufen sowohl Router- als auch Worker-Voreinstellungen mit danger-full-access als Betriebssystembenutzer und können möglicherweise dessen Home-Verzeichnis lesen. Ein dediziertes Konto und ein Wegwerf-Repository sollten vor der Installation und dem Testen eingerichtet werden, nicht erst nach der ersten unerwarteten Aktion.

Das öffentliche Repository ist ein Forschungsprototyp und kein offizielles, produktionsreifes DeepSeek-Produkt. Diese Anleitung überführt die dokumentierten Standardeinstellungen in einen vorsichtigen Einrichtungsplan: getrennte Identitäten, eng begrenzter Repository-Zugriff, überprüfte Zulassungsregeln, kontrollierte Ausführung und ein getestetes Abbruchverfahren. Geben Sie Anmeldedaten nur über Ihr eigenes, genehmigtes Terminal oder Ihren Prozess zur Geheimnisverwaltung ein, niemals in einer Chat-Unterhaltung.

Ist dsh-superagent für den Produktiveinsatz bereit?

In der README steht ausdrücklich, dass es sich um Forschungscode handelt und die veröffentlichte Implementierung vom internen System sowie von einigen Ideen im zugehörigen Designartikel abweicht. Dieser Status sollte bei einer Entscheidung über die Bereitstellung deutlich hervorgehoben werden. Die öffentliche Verfügbarkeit bietet die Gelegenheit, das Design zu prüfen, ist aber keine Garantie dafür, dass der Code für sensible Vorgänge bereit ist.

Diese Anleitung wurde anhand der Revision 8c32a9dc5d72c033816c6a8110b37f40cf94fba4 vom 5. November 2026 geprüft. Legen Sie die tatsächlich geprüfte Revision fest und dokumentieren Sie sie. Wenn Sie den Checkout später aktualisieren, prüfen Sie vor der erneuten Ausführung die Voraussetzungen, Berechtigungen, Voreinstellungen und Konfigurationsmigrationen erneut.

Das Einrichtungsdokument beschreibt einen interaktiven Ablauf mit Planung und Bestätigung. Prüfen Sie den Plan vor der Ausführung. Betrachten Sie die Anweisung, einen Coding-Agent bei der Einrichtung helfen zu lassen, nicht als Erlaubnis, auf nicht dazugehörige Anmeldedaten zuzugreifen oder ihn in Ihrem üblichen Arbeitsprofil zu installieren.

Das erste Abnahmeziel sollte bescheiden sein: Eine harmlose Anfrage erzeugt eine verständliche Aufgabe und ein überprüfbares Ergebnis in einem Wegwerf-Repository. Testen Sie auch das Ablehnungs- und Abbruchverhalten. Eine erfolgreiche Demonstration des optimalen Ablaufs belegt weder Zuverlässigkeit im Produktivbetrieb noch rechtfertigt sie eine sofortige Ausweitung der Zugriffsrechte.

Warum ein dediziertes Betriebssystemkonto verwenden?

In der Bereitstellungsanleitung wird die Annahme zum Host-Zugriff ausdrücklich gemacht. Getrennte Sitzungsverzeichnisse und Anmeldeinformations-Wrapper isolieren den Prozess nicht. Ein Worker kann Programme ausführen und auf Dateien zugreifen, die für das Konto zugänglich sind, unter dem er läuft, einschließlich des Home-Verzeichnisses dieses Kontos.

Erstelle ein dediziertes Konto, das nur die für das Experiment erforderlichen Dateien und Zugangsdaten enthält. Halte persönliche SSH-Schlüssel, Cloud-Administrator-Anmeldedaten, Browserprofile, Produktionskonfigurationen und nicht zugehörige Repositories außerhalb seiner zugänglichen Umgebung. Prüfe neben dem Home-Verzeichnis des Kontos auch die Gruppenmitgliedschaften und eingebundenen Speicher.

Für eine stärkere Trennung solltest du eine dedizierte Wegwerf-VM oder eine ähnlich kontrollierte Hostumgebung in Betracht ziehen. Gehe nicht allein deshalb davon aus, dass ein Container ausreicht, weil er eine andere Dateisystemansicht hat; Mounts, Berechtigungen, Sockets und Netzwerk bestimmen die tatsächliche Grenze. Die Entscheidung über die Bereitstellung sollte den Wert des Hosts und des ausgeführten Codes berücksichtigen.

Unser Architekturüberblick erläutert, warum diese Kontrollen auf verschiedenen Ebenen angesiedelt sind. Durch die Trennung der Ebenen wird verhindert, dass eine eng begrenzte Schutzmaßnahme, etwa eine kurze Liste von Anfragenden, fälschlich als umfassende Isolation verstanden wird.

Titelbild: dsh-superagent-Prototyp-Repository, von GitHub generierte Repository-Karte. Die Repository-Metadaten sind eine datierte Illustration, keine Aussage zu Verbreitung oder Leistung.

Wie erstellt man eine GitHub-Agentenidentität?

Verwende den für den aktuellen Prototyp erforderlichen Ansatz mit einem dedizierten GitHub-Benutzerkonto statt deines persönlichen Kontos. Laut Bereitstellungsanleitung liest diese Implementierung die Benachrichtigungen des Kontos und unterstützt es nicht, eine GitHub App als Identität des Agenten einzusetzen. Das ist eine Einschränkung dieser Implementierung und keine allgemeine Empfehlung gegen GitHub Apps in anderen Systemen.

Gewähre zunächst nur Zugriff auf das Wegwerf-Test-Repository. Halte die Anmeldekonfiguration des Agenten getrennt von deiner eigenen. Verwende den dokumentierten Wrapper-Ansatz oder eine gleichwertige genehmigte Konfiguration und prüfe, welches Konto die CLI verwendet, bevor du dem Prozess erlaubst, aktiv zu werden. Leite die Identität nicht aus einem Anzeigenamen im Chat ab.

Die Hinweise zu GitHubs Tokens erläutern Berechtigungs- und Ablaufoptionen. Wähle für die dokumentierten Abläufe des Prototyps die geringstmöglichen unterstützten Zugriffsrechte, prüfe mögliche Kompatibilitätsanforderungen und stelle sicher, dass sich der Zugriff widerrufen lässt. Vermeide es, dem Konto aus Bequemlichkeit Administrationsrechte für die Organisation oder Berechtigungen für Produktionsbereitstellungen zu geben.

Überlasse das Zusammenführen bei einem ersten Experiment den Menschen. Ein Agent, der einen Branch pushen und einen Pull Request öffnen kann, braucht nicht auch die Befugnis, Repository-Schutzmaßnahmen zu ändern oder seine eigene Arbeit anzunehmen. Die Identität sollte die Urheberschaft klar ausweisen und gleichzeitig eine unabhängige Annahmeentscheidung ermöglichen.

Wie funktionieren Listen zugelassener Nutzer und Zulassungsrichtlinien?

Das Autorisierungsdokument unterscheidet zwischen expliziten Anfragen, abgeleiteten Kandidaten und nicht zugelassenen Eingaben. Sowohl zugelassene Identitäten als auch bereichsspezifische Zulassungseinstellungen sind wichtig. Eine kurze Zulassungsliste ist sinnvoll, sollte aber gemeinsam mit dem Empfangsbereich und den Regeln geprüft werden und nicht als einzige Kontrollmaßnahme gelten.

Beginne mit einer bekannten anfragenden Person und einem Repository. Wenn Feishu für den Test nicht erforderlich ist, lass es unkonfiguriert. Jede zusätzliche Quelle ist ein weiterer Ort, an dem Identität, Empfangsbereich, Bot-Verhalten und die Berechtigung, Arbeit anzustoßen, überprüft werden müssen. Füge erst weitere Quellen hinzu, wenn der erste Workflow verstanden ist.

Teste das Richtlinienverhalten mit harmlosen Beispielen. Prüfe, was geschieht, wenn eine zugelassene Person den Agenten anspricht, jemand eine themenfremde Diskussion beginnt und eine Folgeanfrage Arbeiten außerhalb der bestehenden Aufgabe verlangt. Sieh dir den Entscheidungsdatensatz an, statt anzunehmen, dass keine Aktion erfolgt ist, nur weil keine sichtbare Antwort kam.

Repository-Inhalte und zitierte Nachrichten sollten Belege bleiben, keine Richtlinienänderungen. Eine Anweisung in einem Issue oder Dokument darf nicht stillschweigend Zugriff gewähren oder ändern, wer Arbeit anfordern darf. Unser Vergleich mit proactive-agent erklärt, warum diese Unterscheidung bei ereignisgesteuerten Workflows wichtiger ist als in einer einzelnen betreuten Chat-Sitzung.

Warum mit dem Beobachtungsmodus beginnen?

Im dokumentierten Standardmodus observe bewertet das System abgeleitete Kandidaten und hält fest, welche angenommen würden, ohne sie automatisch anzunehmen. So lässt sich nachvollziehen, wie sich konfigurierte Regeln verhalten. Autorisierte explizite Anfragen werden dadurch nicht an der Ausführung gehindert. Es handelt sich also nicht um einen globalen schreibgeschützten Modus oder einen Modus ohne Aktionen.

Halten Sie die technischen Berechtigungen des Experiments auch während der Beobachtung eng begrenzt. Wenn Sie die Weiterleitung untersuchen möchten, ohne wertvolle Änderungen zuzulassen, verwenden Sie entbehrliche Ressourcen und setzen Sie diese Grenze durch die Konfiguration von Host und Repository durch. Verlassen Sie sich nicht auf die Bezeichnung eines Modus, um Ressourcen zu schützen, auf die der Prozess bereits zugreifen kann.

Überprüfen Sie sowohl positive als auch negative Entscheidungen. Eine Regel, die zu viel zulässt, kann unerwünschte Aufgaben auslösen, während eine Regel, die zu wenig zulässt, erwartete Aufgaben unbemerkt übersehen kann. Halten Sie fest, warum das erwartete Ergebnis vom beobachteten abweicht, bevor Sie die Richtlinie bearbeiten. Die Regeln wiederholt auszuweiten, bis eine Demonstration funktioniert, ist kein guter Weg, um einen sicheren Standard festzulegen.

Wechseln Sie nicht routinemäßig bei der Installation zu auto. Dieser Modus erweitert die Möglichkeiten des Systems, anhand passender Regeln vermutete Aufgaben zu starten. Jede spätere Ausweitung sollte einen klar benannten Verantwortlichen, ein geprüftes Regelwerk, eine kontrollierte Evaluierungsdokumentation und eine getestete Möglichkeit zum Stoppen oder Widerrufen des Zugriffs haben.

Wie lassen sich Tokens, Geheimnisse und lokale Dateien schützen?

Halten Sie Zugangsdaten aus Prompts, Repository-Dateien, Screenshots und gewöhnlichen Protokollen heraus. Verwenden Sie im dedizierten Umfeld die freigegebene CLI-Anmeldung oder einen Geheimnisspeicher. Der OWASP-Leitfaden zur Geheimnisverwaltung enthält Hintergrundinformationen zu Zugriffskontrolle und Lebenszyklus. Die unmittelbare Anforderung ist jedoch einfach: Die Umgebung des Agenten sollte keine Zugangsdaten enthalten, die für seine Aufgabe nicht erforderlich sind.

Überprüfen Sie neben der GitHub-Identität auch den Pfad zum Modellanbieter. Code und Prompts können vom konfigurierten Anbieter verarbeitet werden, und Tools können weitere Ziele einführen. Ein lokaler Checkout bedeutet nicht, dass auch die Inferenz lokal erfolgt oder die Daten ausschließlich lokal verarbeitet werden. Vergewissern Sie sich, dass der ausgewählte Anbieter und die Protokollierungskonfiguration für das Testmaterial freigegeben sind.

Kopieren Sie nicht das persönliche Home-Verzeichnis oder die Shell-Konfiguration in das dedizierte Konto, nur um die Einrichtung zu vereinfachen. Dadurch könnten Zugangsdaten-Helfer, Umgebungsvariablen, Cloud-Konfigurationen und private Verlaufsdaten mit übernommen werden. Richten Sie die minimal erforderlichen Abhängigkeiten bewusst neu ein und führen Sie eine nicht vertrauliche Liste der hinzugefügten Elemente.

Unsere Checkliste für den Zugriff des persönlichen Agenten bietet einen passenden Vorbereitungsschritt. Prüfen Sie vor der ersten Ausführung in der tatsächlichen Umgebung des Agenten, auf welche Verzeichnisse, Zugangsdaten, Dienste und Netzwerkziele er zugreifen kann. Ist der Zugriff umfassender als für den Test erforderlich, passen Sie die Grenzen an, bevor Sie fortfahren.

Wie isolieren Sie das Repository und überprüfen Änderungen?

Verwenden Sie ein Wegwerf-Repository mit synthetischen Beispielen und ohne Produktionsgeheimnisse. In der Einrichtungsdokumentation werden unter anderem eine kompatible Node.js-Version, pnpm, Git, tmux, Python, die GitHub CLI und DeepSeek Harness als Voraussetzungen genannt. Prüfen Sie die aktuelle package.json und die Einrichtungsanleitung auf die genaue Kompatibilität, statt beliebige Versionen aus einer alten Befehlsliste zu installieren.

Befolgen Sie diese Vorbereitungsschritte, bevor Sie den Installationsplan ausführen:

1. Richten Sie das dedizierte Konto oder den Wegwerf-Host ein und bestätigen Sie dessen Zugriffsgrenzen.
2. Erstellen Sie die dedizierte GitHub-Identität und ein Test-Repository mit angemessen eingeschränkten Berechtigungen.
3. Rufen Sie den Prototyp ab, notieren Sie seine Revision und prüfen Sie die Einrichtungs- und Bereitstellungsdokumentation.
4. Prüfen Sie den vorgeschlagenen Installationsplan, den Modellanbieter, das Profil, den Speicherort des Status und den Anmeldedatenmechanismus.
5. Konfigurieren Sie für den ersten Test nur die Aufgabenzufuhr über GitHub, eine kurze Liste von Anfragenden, observe und keine automatische Zusammenführung.
6. Starten Sie die geprüfte Konfiguration und prüfen Sie den Zustand sowie die Einrichtungsanforderungen.
7. Übermitteln Sie eine unbedenkliche, autorisierte Aufgabe und prüfen Sie den resultierenden Status sowie den vorgeschlagenen Änderungsvorschlag.
8. Testen Sie irrelevante Eingaben, eine Ausweitung des Umfangs und das Stoppverfahren, bevor Sie einen weitergehenden Zugriff in Betracht ziehen.

Der dokumentierte Statusbefehl ist nach der Einrichtung nützlich:

scripts/dsh-superagent status

Führen Sie es in der geprüften Arbeitskopie der dedizierten Umgebung aus. Interpretieren Sie die Ausgabe anhand der aktuellen Bereitstellungsanleitung; ein laufender Prozess ist nicht gleichbedeutend mit einer gesunden, korrekt konfigurierten Quelle und Richtlinie.

Halten Sie die Anforderungen an geschützte Branches und die menschliche Prüfung aufrecht. Prüfen Sie den Diff, die Ausgangs- und Endrevisionen, Tests und ungelöste Annahmen. Verwenden Sie für wertvolle Daten unabhängige Kopien; unsere Anleitung zu wiederherstellbaren Dateien erklärt, warum die Wiederherstellung geplant werden muss, bevor Schreibzugriff gewährt wird.

Wie stoppen Sie den Agenten und entziehen ihm den Zugriff?

Dokumentieren Sie das Stoppverfahren vor der ersten Aufgabe. Die aktuelle Bereitstellungsanleitung enthält einen Befehl zum ordnungsgemäßen Stoppen:

scripts/dsh-superagent stop
scripts/dsh-superagent status

Ein ordnungsgemäßes Stoppen kann warten, bis die Ausführung abgeschlossen ist; es beweist nicht, dass alle externen Auswirkungen rückgängig gemacht wurden. Prüfen Sie offene Arbeiten und relevante Repository-Aktivitäten. Beenden Sie nicht wahllos andere Sitzungen, anstatt zu verstehen, was der Prozess gerade tut.

Bei einem Zugriffsincident oder einem aufgegebenen Experiment entziehen Sie die dedizierten Zugangsdaten und den Repository-Zugriff über die entsprechenden Einstellungen des Anbieters. Stoppen Sie die Annahme neuer Aufgaben und prüfen Sie verbleibende Hintergrundprozesse oder Dienste. Bewahren Sie eine nicht vertrauliche Aufzeichnung der betroffenen Aufgabe, Revision und relevanten Aktivitäten auf, damit das Team den Vorfall nachvollziehen kann.

Bereinigung und Wiederherstellung sind unterschiedliche Aufgaben. Das Löschen eines lokalen Verzeichnisses widerruft kein Token, schließt keinen Remote-Pull-Request und macht keine bereits gepushte Änderung rückgängig. Lege für jedes Artefakt gesondert fest, was damit geschehen soll, und sichere benötigte Belege, bevor du es entfernst. Weite das Experiment erst aus, wenn Abbruch, Widerruf und Wiederherstellung genauso verständlich sind wie der Start.

Für das Ergebnis selbst verwende das Prüfverfahren für agentic-autofix. Ein funktionierender Prozess und eine angenommene Aufgabe sind operative Signale; sie belegen nicht, dass der vorgeschlagene Patch zusammengeführt werden sollte.

FAQ

Kann ich den Prototyp über mein normales Entwicklerkonto ausführen?

Dadurch erhält der Prozess Zugriff auf die erreichbaren Dateien und Zugangsdaten des Kontos. Verwende für den ersten Versuch eine dedizierte, eingeschränkte Umgebung, insbesondere angesichts der dokumentierten Voreinstellungen mit Vollzugriff.

Ist der Prototyp im Beobachtungsmodus schreibgeschützt?

Nein. Dadurch wird die Annahme erschlossener Kandidaten eingeschränkt, während ausdrücklich autorisierte Anfragen weiterhin ausgeführt werden können. Wenn das Testziel darin besteht, Schreibzugriffe auszuschließen, setze dies über Berechtigungen durch.

Kann ich statt eines dedizierten Benutzerkontos eine GitHub App verwenden?

Der geprüfte Bereitstellungsleitfaden des Prototyps verlangt wegen seines Benachrichtigungsablaufs ein Benutzerkonto. Prüfe spätere Versionen erneut, bevor du davon ausgehst, dass diese Kompatibilitätsbeschränkung unverändert gilt.

Soll ich Einrichtungstoken in den Chat des Assistenzagenten einfügen?

Nein. Verwende die genehmigte CLI-Authentifizierung oder die Geheimnisverwaltung in deiner eigenen kontrollierten Umgebung. Für die Einrichtung müssen keine Geheimniswerte im Gespräch offengelegt werden.

Was belegt, dass der anfängliche Versuch sicher ausgeweitet werden kann?

Kein einzelner Test belegt allgemeine Sicherheit. Prüfe Entscheidungen bei der Aufgabenannahme, Berechtigungsgrenzen, vorgeschlagene Änderungen, das Abbruchverhalten und Belege zur Wiederherstellung. Gib anschließend nur einen konkret festgelegten zusätzlichen Umfang frei.

Fazit

Die sichere Einrichtung von dsh-superagent beginnt mit seinen tatsächlichen Betriebsannahmen: Forschungsstatus, Ausführung mit Vollzugriff unter dem Host-Benutzer und ein Beobachtungsmodus, der ausdrücklich beauftragte Aufgaben weiterhin zulässt. Dedizierte Identitäten, kurzlebige Ressourcen und eine unabhängige Prüfung sind Voraussetzungen, um das Verhalten des Prototyps kennenzulernen.

Halte die erste Aufgabe eng begrenzt, teste Ablehnung und Abbruch ebenso gezielt wie Erfolg und bewahre die Belege für jede angenommene Änderung auf. Mache aus einem nützlichen Forschungsexperiment keine Produktionsbereitstellung, indem du nach und nach Zugangsdaten und Befugnisse ansammelst, ohne eine erneute Prüfung.