Leitfaden · Aktualisiert am 10. November 2026 · Von Cameron Voss und West Mao

DeepSeek SuperAgent-Sicherheit: Berechtigungen, Beobachtungsmodus und sichere Einrichtung (November 2026)

Eine praktische Sicherheitscheckliste zur Bewertung des Forschungsprototyps auf einem GitHub-Repository.

Kurze Antwort

Beginnen Sie mit einem Test-Repository, einem eigenen GitHub-Konto für den Agenten, einer kurzen Liste zugelassener Anforderer und einer isolierten Laufzeitumgebung. Behalten Sie menschliche Reviews und Branch-Schutz bei. Der Observe-Modus begrenzt abgeleitete Aufgaben, verhindert aber weder ausdrückliche Anfragen noch isoliert er den Worker in einer Sandbox.

DeepSeek SuperAgent ist ein Forschungsprototyp, der auf DeepSeek Harness basiert, kein offizielles DeepSeek-Produkt oder produktionsreife Software. Es benötigt einen separat konfigurierten Modellanbieter. Dieses Handbuch folgt der veröffentlichten Dokumentation; Für diesen Artikel haben wir keine End-to-End-Bereitstellung durchgeführt.

Der öffentliche Prototyp koordiniert die Agentenarbeit in GitHub-Konversationen. Ein Sicherheitsplan muss berücksichtigen, wer Arbeit anfordern kann und was der resultierende Worker erreichen kann. In diesem Artikel wird das dokumentierte Design erläutert und ein enger Test empfohlen. Es handelt sich nicht um eine Sicherheitszertifizierung oder um das Ergebnis eines Penetrationstests.

Auf was kann der Agent zugreifen, wenn er ausgeführt wird?

In der veröffentlichten Bereitstellungsdokumentation heißt es, dass die Router- und Worker-Voreinstellungen mit danger-full-access als Betriebssystembenutzer des Dienstes ausgeführt werden. Ein Worker kann Programme ausführen und Dateien lesen, die diesem Benutzer zur Verfügung stehen. Es kann auch die GitHub-Anmeldeinformationen des Agenten verwenden, um mit seinem konfigurierten Repository zu interagieren.

Eine dedizierte GitHub-Identität ist nützlich für die Zuordnung und Einschränkung des Repository-Zugriffs, isoliert jedoch nicht den lokalen Prozess. Ein Verzeichnis pro Ticket oder ein Git-Arbeitsbaum trennt Änderungen für die Organisation; Der Dateisystem-, Netzwerk- oder Anmeldeinformationszugriff wird nicht blockiert.

Was macht der Beobachtungsmodus eigentlich?

Akzeptanzmodus	Abgeleitete Kandidaten	Explizite autorisierte Anfrage
`off`	Abgeleitete Aktivität wird nicht zu einem Kandidaten.	Kann immer noch sein akzeptiert.
`observe`	Bewertet; Ein positives Ergebnis wird als „würde annehmen“ erfasst, ohne mit der abgeleiteten Arbeit zu beginnen.	Kann weiterhin akzeptiert werden.
`auto`	Eine positive Bewertung kann Arbeit annehmen, wenn eine aktivierte Regel übereinstimmt.	Kann weiterhin akzeptiert werden.

Beginnen Sie in observe, um zu prüfen, ob Regeln nützliche oder laute Arbeit generieren würden. Es handelt sich um eine Richtlinieneinstellung für abgeleitete Aktivitäten und nicht um einen Probelaufschalter für alle Agentenaktionen. Die adressierte Anfrage einer berechtigten Person kann ein Ticket erstellen und einen Arbeiter in jedem dieser Modi ausführen.

Wer kann mit der Arbeit beginnen und wer kann ein Gespräch fortsetzen?

Der Host wendet Quellrichtlinien und Zulassungslisten an, wenn er entscheidet, ob eine neue Anfrage zugelassen wird. Eine berechtigte Person, die sich an den Agenten wendet, kann eine explizite Anfrage stellen. Andere Nachrichten können gemäß der Quellrichtlinie als abgeleitete Kandidaten ausgewertet werden.

Sobald ein Ticket einen Thread abonniert, können Nachrichten in diesem Thread ihn als Kontext erreichen, einschließlich Bot- und CI-Nachrichten. Sie gewähren nicht von sich aus neue Befugnisse: Das Mandat des Tickets definiert immer noch seinen Umfang. Die Dokumentation besagt auch, dass die Nachricht einer Person im eigenen Thread eines beendeten Tickets diese Arbeit fortsetzen kann, unabhängig vom Absender. Berücksichtigen Sie bei einem öffentlichen Repository, wer Material in abonnierten Threads posten oder beeinflussen kann; Eine kurze Zulassungsliste für Anfragende allein macht nicht alle späteren Eingaben vertrauenswürdig.

Was schützt vor Prompt Injection?

Keine einzelne Einstellung beseitigt es. Problemtexte, Kommentare, Protokolle und Repository-Dateien können Anweisungen von Personen enthalten, die den Agenten nicht kontrollieren sollten. Das dokumentierte Autorisierungsmodell behandelt diese Nachrichten als Eingaben und nicht als Berechtigungsänderungen, aber ein Modell kann dennoch feindliche Inhalte falsch interpretieren oder im Rahmen der bereits vorhandenen Berechtigungen agieren.

Verwenden Sie ein privates Test-Repository und begrenzen Sie, wer während der Testlauf Beiträge oder Kommentare abgeben kann.
Führen Sie es mit einer dedizierten Betriebssystemidentität und nur den Anmeldeinformationen und Dateien aus, die für die Testlauf erforderlich sind. Erwägen Sie eine separat verwaltete VM oder eine gleichwertige Isolierung mit eingeschränktem Netzwerkzugriff.
Legen Sie keine Produktionsgeheimnisse, Anmeldeinformationen für die Bereitstellung oder nicht verwandte private Repositorys in die Arbeitsumgebung.
Schützen Sie den Standardzweig und verlangen Sie, dass vor der Zusammenführung ein Mensch das Diff und die Tests überprüft.
Überwachen Sie das Agentenkonto und seien Sie bereit, seine Anmeldeinformationen zu widerrufen und den Dienst zu stoppen.

Dies sind Maßnahmen zur Risikominderung, keine Garantie. Die geeigneten Kontrollen hängen vom Repository, der Hosting-Umgebung und den Folgen eines Fehlers ab.

Wie sollten Sie die erste Testlauf konfigurieren?

Begrenzen Sie das Ziel. Wählen Sie ein Test-Repository mit geringem Risiko und eine kleine Dokumentationsaufgabe.
Getrennte Identitäten. Verwenden Sie einen Nur-Agenten-GitHub-Benutzer und eine CLI-Konfiguration. Gewähren Sie diesem Benutzer nur Zugriff auf das Test-Repository.
Reduzieren Sie den Hostzugriff. Verwenden Sie ein dediziertes Betriebssystemkonto und überprüfen Sie Bereitstellungen, erreichbare Dienste, Umgebungsvariablen und Netzwerkzugriff.
Legen Sie eine Richtlinie fest. Lassen Sie nur den vorgesehenen Anforderer zu und beginnen Sie mit der abgeleiteten Akzeptanz in observe.
Überprüfen Sie menschlich. Deaktivieren Sie die automatische Zusammenführung. Verwenden Sie den Zweigschutz und überprüfen Sie jede PR und das Ergebnis.
Testen Sie die Grenzen. Überprüfen Sie den Ticketstatus, die tatsächlich geänderten Dateien und die für die Laufzeit verfügbaren Anmeldeinformationen. Zeichnen Sie unerwartetes Verhalten auf und stoppen Sie, wenn der Umfang unklar ist.

Hört eine Änderung der Richtlinie die bestehende Arbeit sofort auf?

Nicht unbedingt. In der Dokumentation heißt es, dass Richtlinienänderungen betroffene Live-Tickets benachrichtigen, aber nicht sofort jedes aktive Mandat widerrufen. Wenn Sie die Arbeit stoppen müssen, verwenden Sie die Stoppkontrollen des Projekts, überprüfen Sie aktive Tickets und laufende Prozesse und widerrufen Sie gegebenenfalls Anmeldeinformationen oder Zugriff. Überprüfen Sie das Ergebnis, anstatt davon auszugehen, dass eine Konfigurationsbearbeitung jeden Worker gestoppt hat.

Kann SuperAgent seine eigenen Pull Requestn zusammenführen?

Das Projekt empfiehlt, mit der menschlichen Zusammenführung zu beginnen. Es beschreibt eine optionale automatische Zusammenführungsanordnung mit zusätzlichen Steuerelementen; Gehen Sie nicht davon aus, dass eine Eingabeaufforderung allein die Richtlinie Ihres Repositorys durchsetzt. Lassen Sie die automatische Zusammenführung während der Testlauf deaktiviert und nutzen Sie die Repository-Steuerelemente von GitHub, um die Überprüfungen und Prüfungen anzufordern, die Ihr Team benötigt.

Was sollten Sie überprüfen, bevor Sie den Zugriff erweitern?

Frage	Beweise, nach denen gesucht werden muss
Kann der Agent nur auf vorgesehene Repositorys zugreifen?	Agent-Kontomitgliedschaft und Repository-Berechtigungen.
Kann ein Worker auf nicht verwandte Geheimnisse zugreifen?	OS Konto, Bereitstellungen, Umgebung, Anmeldeinformationsspeicher und Netzwerkregeln.
Sind Entscheidungen verständlich?	Beobachtete Kandidaten, zugelassene Anforderer, Ticketmandate und Protokolle.
Wird jede Änderung überprüft?	Branchenschutz, Prüferanforderungen und ein manueller Zusammenführungsprozess.
Kann das Team aufhören und wiederherstellen?	Prozedur stoppen, Zugangsdaten widerrufen, Sicherung und ein benannter Operator.

Informationen zu den Anforderungen und Betriebskosten finden Sie im Einrichtungs- und Kostenleitfaden für SuperAgent. Informationen zum internen Fluss zwischen Quellen, Tickets und Arbeitern finden Sie im Architekturleitfaden.

Häufig gestellte Fragen

Ist die Verwendung des Beobachtungsmodus mit Produktionsanmeldeinformationen sicher?

Der Beobachtungsmodus schützt Anmeldeinformationen nicht vor einer expliziten Aufgabe und isoliert keine Worker. Halten Sie Produktionsanmeldeinformationen von einer Testlauf fern.

Sandboxt ein dedizierter GitHub-Benutzer den Worker?

Nein. Es trennt die GitHub-Identität; Betriebssystem- und Infrastrukturkontrollen bestimmen, was der Prozess erreichen kann.

Ist der Prototyp serienreif?

Die Betreuer beschreiben es als Forschungscode zum Überprüfen und Anpassen, nicht als produktionsreife Software.

Preise der Coding Plans ansehen